Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: KVM: No sobrescribir el tipo de enrutamiento de irqfd al desasignar irqfd Al desasignar un KVM_IRQFD, no sobrescribir la copia del irqfd de la entrada de enrutamiento de la IRQ, ya que hacerlo rompe kvm_arch_irq_bypass_del_producer() en x86 y arm64, que buscan explícitamente KVM_IRQ_ROUTING_MSI. En su lugar, para manejar una actualización de enrutamiento concurrente, verificar que el irqfd sigue activo antes de consumir la información de enrutamiento. Como lo demuestran los errores de x86 y arm64, y otro error en kvm_arch_update_irqfd_routing() (ver abajo), sobrescribir el tipo de entrada sin notificar al código de arquitectura es sorprendente y propenso a errores. Como ventaja adicional, verificar que el irqfd está activo proporciona una ubicación conveniente para documentar _por qué_ KVM no debe consumir la entrada de enrutamiento para un irqfd que está en proceso de ser desasignado: una vez que el irqfd se elimina de la lista (lo que ocurre *antes* de que el eventfd se desvincule), ya no recibirá actualizaciones a través de kvm_irq_routing_update(), y así KVM podría entregar un evento utilizando información de enrutamiento obsoleta (en relación con KVM_SET_GSI_ROUTING que regresa al espacio de usuario). Como una ventaja aún mejor, verificar explícitamente que el irqfd está activo corrige un error similar al que el sobrescrito intenta prevenir: si un irqfd se desactiva y luego se cambia su enrutamiento, kvm_irq_routing_update() no invocará a kvm_arch_update_irqfd_routing() (porque el irqfd no está en la lista). Y así, si el irqfd está en modo de bypass, las IRQ seguirán siendo publicadas utilizando la información de enrutamiento antigua. En cuanto a kvm_arch_irq_bypass_del_producer(), sobrescribir el tipo de enrutamiento resulta en que KVM mantiene incorrectamente la IRQ en modo de bypass, lo cual es especialmente problemático en AMD, ya que KVM rastrea las IRQ que se están publicando a una vCPU en una lista cuya vida útil está ligada al irqfd. Sin la ayuda de KASAN para detectar el uso después de liberación, el síntoma más común en AMD es una desreferencia de puntero NULL en amd_iommu_update_ga() debido a que la memoria para la estructura irqfd se reasigna y se pone a cero, lo que resulta en que irqfd->irq_bypass_data sea NULL cuando es leído por avic_update_iommu_vcpu_affinity(): BUG: desreferencia de puntero NULL del kernel, dirección: 0000000000000018 #PF: acceso de lectura de supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD 40cf2b9067 P4D 40cf2b9067 PUD 408362a067 PMD 0 Oops: Oops: 0000 [#1] SMP CPU: 6 UID: 0 PID: 40383 Comm: vfio_irq_test Tainted: G U W O 6.19.0-smp--5dddc257e6b2-irqfd #31 NONE Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE Nombre de hardware: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025 RIP: 0010:amd_iommu_update_ga+0x19/0xe0 Traza de Llamada: avic_update_iommu_vcpu_affinity+0x3d/0x90 [kvm_amd] __avic_vcpu_load+0xf4/0x130 [kvm_amd] kvm_arch_vcpu_load+0x89/0x210 [kvm] vcpu_load+0x30/0x40 [kvm] kvm_arch_vcpu_ioctl_run+0x45/0x620 [kvm] kvm_vcpu_ioctl+0x571/0x6a0 [kvm] __se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x6f/0x9d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x46893b ---[ fin de la traza 0000000000000000 ]--- Si AVIC se inhibe cuando el irqfd es desasignado, el error se manifestará como corrupción de lista, por ejemplo, en la siguiente asignación de irqfd. Corrupción de list_add. next->prev debería ser prev (ffff8d474d5cd588), pero era 0000000000000000. (next=ffff8d8658f86530). ------------[ cortar aquí ]------------ BUG del kernel en lib/list_debug.c:31! Oops: código de operación inválido: 0000 [#1] SMP CPU: 128 UID: 0 PID: 80818 Comm: vfio_irq_test Tainted: G U W O 6.19.0-smp--f19dc4d680ba-irqfd #28 NONE---truncado---

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ceph: corrige un oops debido a un puntero inválido para kfree() en parse_longname()<br /> <br /> Esto corrige un oops del kernel al leer directorios de instantáneas de ceph (.snap), por ejemplo, simplemente ejecutando &amp;#39;ls /mnt/my_ceph/.snap&amp;#39;.<br /> <br /> La variable str está protegida por __free(kfree), pero se avanza en uno para saltar el &amp;#39;_&amp;#39; inicial en los nombres de las instantáneas. Por lo tanto, se llama a kfree() con un puntero inválido. Este parche elimina la necesidad de avanzar el puntero para que se llame a kfree() con el puntero de memoria correcto.<br /> <br /> Pasos para reproducir:<br /> <br /> 1. Crea instantáneas en un volumen cephfs (tengo 63 instantáneas en mi caso de prueba)<br /> <br /> 2. Añade el montaje cephfs a fstab<br /> $ echo &amp;#39;samba-fileserver@.files=/volumes/datapool/stuff/3461082b-ecc9-4e82-8549-3fd2590d3fb6 /mnt/test/stuff ceph acl,noatime,_netdev 0 0&amp;#39; &amp;gt;&amp;gt; /etc/fstab<br /> <br /> 3. Reinicia el sistema<br /> $ systemctl reboot<br /> <br /> 4. Comprueba si está realmente montado<br /> $ mount | grep stuff<br /> <br /> 5. Lista las instantáneas (se esperan 63 instantáneas en mi sistema)<br /> $ ls /mnt/test/stuff/.snap<br /> <br /> Ahora ls se cuelga indefinidamente y el registro del kernel muestra el oops.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ipv6: Solucionar desajuste en el recuento de hermanos ECMP al borrar RTF_ADDRCONF<br /> <br /> syzbot informó un BUG del kernel en fib6_add_rt2node() al añadir una ruta IPv6. [0]<br /> <br /> El commit f72514b3c569 (&amp;#39;ipv6: borrar flags RA al añadir una ruta estática&amp;#39;) introdujo lógica para borrar RTF_ADDRCONF de rutas existentes cuando se añade una ruta estática con el mismo nexthop. Sin embargo, esto causa un problema cuando la ruta existente tiene una puerta de enlace.<br /> <br /> Cuando se borra RTF_ADDRCONF de una ruta que tiene una puerta de enlace, esa ruta se vuelve elegible para ECMP, es decir, rt6_qualify_for_ecmp() devuelve verdadero. El problema es que esta ruta nunca fue añadida a la lista fib6_siblings.<br /> <br /> Esto lleva a un desajuste entre los siguientes recuentos:<br /> <br /> - El recuento de hermanos calculado al iterar la cadena fib6_next, que incluye la ruta recién elegible para ECMP<br /> <br /> - Los hermanos reales en la lista fib6_siblings, que no incluye esa ruta<br /> <br /> Cuando se añade una ruta ECMP subsiguiente, fib6_add_rt2node() encuentra BUG_ON(sibling-&amp;gt;fib6_nsiblings != rt-&amp;gt;fib6_nsiblings) porque los recuentos no coinciden.<br /> <br /> Solucione esto borrando RTF_ADDRCONF solo cuando la ruta existente no tiene una puerta de enlace. Las rutas sin una puerta de enlace no pueden calificar para ECMP de todos modos (rt6_qualify_for_ecmp() requiere fib_nh_gw_family), por lo tanto, borrar RTF_ADDRCONF en ellas es seguro y coincide con la intención original del commit.<br /> <br /> [0]:<br /> BUG del kernel en net/ipv6/ip6_fib.c:1217!<br /> Oops: código de operación inválido: 0000 [#1] SMP KASAN PTI<br /> CPU: 0 UID: 0 PID: 6010 Comm: syz.0.17 No contaminado syzkaller #0 PREEMPT(full)<br /> Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025<br /> RIP: 0010:fib6_add_rt2node+0x3433/0x3470 net/ipv6/ip6_fib.c:1217<br /> [...]<br /> Traza de llamada:<br /> <br /> fib6_add+0x8da/0x18a0 net/ipv6/ip6_fib.c:1532<br /> __ip6_ins_rt net/ipv6/route.c:1351 [en línea]<br /> ip6_route_add+0xde/0x1b0 net/ipv6/route.c:3946<br /> ipv6_route_ioctl+0x35c/0x480 net/ipv6/route.c:4571<br /> inet6_ioctl+0x219/0x280 net/ipv6/af_inet6.c:577<br /> sock_do_ioctl+0xdc/0x300 net/socket.c:1245<br /> sock_ioctl+0x576/0x790 net/socket.c:1366<br /> vfs_ioctl fs/ioctl.c:51 [en línea]<br /> __do_sys_ioctl fs/ioctl.c:597 [en línea]<br /> __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [en línea]<br /> do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> procfs: evitar la obtención del ID de compilación mientras se mantiene el bloqueo VMA<br /> <br /> Corregir PROCMAP_QUERY para obtener el ID de compilación opcional solo después de liberar mmap_lock o el bloqueo por VMA, el que se haya utilizado para bloquear el VMA en cuestión, para evitar el interbloqueo informado por syzbot:<br /> <br /> -&amp;gt; #1 (&amp;amp;mm-&amp;gt;mmap_lock){++++}-{4:4}:<br /> __might_fault+0xed/0x170<br /> _copy_to_iter+0x118/0x1720<br /> copy_page_to_iter+0x12d/0x1e0<br /> filemap_read+0x720/0x10a0<br /> blkdev_read_iter+0x2b5/0x4e0<br /> vfs_read+0x7f4/0xae0<br /> ksys_read+0x12a/0x250<br /> do_syscall_64+0xcb/0xf80<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> -&amp;gt; #0 (&amp;amp;sb-&amp;gt;s_type-&amp;gt;i_mutex_key#8){++++}-{4:4}:<br /> __lock_acquire+0x1509/0x26d0<br /> lock_acquire+0x185/0x340<br /> down_read+0x98/0x490<br /> blkdev_read_iter+0x2a7/0x4e0<br /> __kernel_read+0x39a/0xa90<br /> freader_fetch+0x1d5/0xa80<br /> __build_id_parse.isra.0+0xea/0x6a0<br /> do_procmap_query+0xd75/0x1050<br /> procfs_procmap_ioctl+0x7a/0xb0<br /> __x64_sys_ioctl+0x18e/0x210<br /> do_syscall_64+0xcb/0xf80<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> otra información que podría ayudarnos a depurar esto:<br /> <br /> Posible escenario de bloqueo inseguro:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> rlock(&amp;amp;mm-&amp;gt;mmap_lock);<br /> lock(&amp;amp;sb-&amp;gt;s_type-&amp;gt;i_mutex_key#8);<br /> lock(&amp;amp;mm-&amp;gt;mmap_lock);<br /> rlock(&amp;amp;sb-&amp;gt;s_type-&amp;gt;i_mutex_key#8);<br /> <br /> * INTERBLOQUEO *<br /> <br /> Esto parece exacerbarse (ya que no habíamos visto estos informes de syzbot antes de eso) por el reciente:<br /> <br /> 777a8560fd29 ("lib/buildid: use __kernel_read() for sleepable context")<br /> <br /> Para que esto sea seguro, necesitamos tomar el recuento de referencias del archivo mientras el VMA aún está bloqueado, pero aparte de eso, todo es bastante sencillo. La API interna build_id_parse() asume que se pasa el VMA, pero solo necesita la referencia de archivo subyacente, así que solo hay que añadir otra variante build_id_parse_file() que espera que el archivo se pase directamente.<br /> <br /> [akpm@linux-foundation.org: corregir kerneldoc]

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> i2c: imx: preservar el estado de error en el manejador de longitud de datos de bloque<br /> <br /> Cuando una lectura de bloque devuelve una longitud no válida, cero o &amp;gt;I2C_SMBUS_BLOCK_MAX, el manejador de longitud establece el estado a IMX_I2C_STATE_FAILED. Sin embargo, i2c_imx_master_isr() sobrescribe incondicionalmente esto con IMX_I2C_STATE_READ_CONTINUE, causando un bucle de lectura infinito que desborda los búferes y bloquea el sistema.<br /> <br /> Proteger la transición de estado para preservar los estados de error establecidos por el manejador de longitud.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> HID: Intel-thc-hid: Intel-thc: Añadir comprobación de seguridad para la lectura del búfer DMA<br /> <br /> Añadir comprobación de disponibilidad del búfer DMA antes de leer el búfer DMA para evitar el acceso inesperado a punteros NULL.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> rust_binder: manejar correctamente los objetos FDA de longitud cero<br /> <br /> Se corrige un error donde un objeto FDA (matriz de descriptores de archivo) vacío con 0 descriptores de archivo causaría un error de fuera de límites. La implementación anterior utilizaba &amp;#39;skip == 0&amp;#39; para significar &amp;#39;esto es una corrección de puntero&amp;#39;, pero 0 es también la longitud de salto correcta para un FDA vacío. Si el FDA está al final del búfer, entonces esto resulta en un intento de escribir 8 bytes fuera de los límites. Esto es detectado y resulta en que se devuelve un error EINVAL al espacio de usuario.<br /> <br /> El patrón de usar &amp;#39;skip == 0&amp;#39; como un valor especial se origina en la implementación en C de Binder. Como parte de la corrección de este error, este patrón es reemplazado con un enum de Rust.<br /> <br /> Consideré la opción alternativa de no aplicar una corrección cuando la longitud es cero, pero creo que es más limpio simplemente eliminar lo de "cero es especial".<br /> <br /> La causa raíz de este error fue diagnosticada por Gemini CLI al primer intento. Utilicé el siguiente prompt:<br /> <br /> &amp;gt; Parece haber un error en @drivers/android/binder/thread.rs donde el error de fuera de límites (oob) de Fixups se activa con 316 304 316 324. Esto implica que de alguna manera terminamos con una corrección donde el búfer A tiene un puntero al búfer B, pero el puntero está ubicado en un índice en el búfer A que está fuera de los límites. Por favor, investigue el código para encontrar el error. Puede comparar con @drivers/android/binder.c que implementa esto correctamente.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> binder: corregir UAF en binder_netlink_report()<br /> <br /> Las transacciones unidireccionales enviadas a objetivos congelados a través de binder_proc_transaction() devuelven un error BR_TRANSACTION_PENDING_FROZEN pero aún se tratan como exitosas ya que se espera que el objetivo se descongele en algún momento. Por lo tanto, no es seguro acceder a &amp;#39;t&amp;#39; después de errores BR_TRANSACTION_PENDING_FROZEN, ya que la transacción podría haber sido consumida por el objetivo ahora descongelado.<br /> <br /> Este es el caso de binder_netlink_report() que desreferencia &amp;#39;t&amp;#39; después de un error de congelación pendiente, como lo señala el siguiente informe KASAN:<br /> <br /> ==================================================================<br /> ERROR: KASAN: uso después de liberación de slab en binder_netlink_report.isra.0+0x694/0x6c8<br /> Lectura de tamaño 8 en la dirección ffff00000f98ba38 por la tarea binder-util/522<br /> <br /> CPU: 4 UID: 0 PID: 522 Comm: binder-util No contaminado 6.19.0-rc6-00015-gc03e9c42ae8f #1 PREEMPT<br /> Nombre del hardware: linux,dummy-virt (DT)<br /> Rastro de llamada:<br /> binder_netlink_report.isra.0+0x694/0x6c8<br /> binder_transaction+0x66e4/0x79b8<br /> binder_thread_write+0xab4/0x4440<br /> binder_ioctl+0x1fd4/0x2940<br /> [...]<br /> <br /> Asignado por la tarea 522:<br /> __kmalloc_cache_noprof+0x17c/0x50c<br /> binder_transaction+0x584/0x79b8<br /> binder_thread_write+0xab4/0x4440<br /> binder_ioctl+0x1fd4/0x2940<br /> [...]<br /> <br /> Liberado por la tarea 488:<br /> kfree+0x1d0/0x420<br /> binder_free_transaction+0x150/0x234<br /> binder_thread_read+0x2d08/0x3ce4<br /> binder_ioctl+0x488/0x2940<br /> [...]<br /> ==================================================================<br /> <br /> En su lugar, haga una copia de la transacción para que los datos puedan ser accedidos de forma segura por binder_netlink_report() después de un error de congelación pendiente. Ya que estamos, añada un comentario sobre no usar t-&amp;gt;buffer en binder_netlink_report().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> wifi: iwlwifi: mld: cancelar mlo_scan_start_wk<br /> <br /> mlo_scan_start_wk no se cancela en la desconexión. De hecho, no se<br /> cancela en ningún otro lugar excepto en la limpieza de reinicio, donde<br /> realmente no es necesario.<br /> <br /> Esto puede causar un problema de inicialización después de la cola: si,<br /> por ejemplo, el trabajo fue puesto en cola y luego se ejecutó<br /> drv_change_interface.<br /> <br /> Esto también puede causar uso después de liberación: si el trabajo se<br /> ejecuta después de que se libera el vif.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ALSA: aloop: Corrige el acceso con condiciones de carrera en el disparador PCM<br /> <br /> La función de devolución de llamada del disparador PCM del controlador aloop intenta verificar el estado de PCM y detener el flujo del subflujo vinculado en el cable correspondiente. Dado que tanto las operaciones de verificación como las de detención se realizan fuera del bloqueo del cable, esto puede resultar en UAF cuando un programa intenta disparar frecuentemente mientras abre/cierra el flujo vinculado, como detectaron los fuzzers.<br /> <br /> Para abordar el UAF, este parche cambia dos cosas:<br /> - Cubre la mayor parte del código en loopback_check_format() con el spinlock cable-&amp;gt;lock, y añade las comprobaciones de NULL adecuadas. Esto ya evita algunos accesos con condiciones de carrera.<br /> - Además, ahora intentamos verificar el estado del flujo PCM de captura que puede ser detenido en esta función, lo cual era el principal punto problemático que conducía al UAF.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> hwmon: (acpi_power_meter) Soluciona interbloqueos relacionados con acpi_power_meter_notify()<br /> <br /> La función de callback .notify() del controlador acpi_power_meter, acpi_power_meter_notify(), llama a hwmon_device_unregister() bajo un bloqueo que también es adquirido por callbacks en atributos sysfs del dispositivo que se está desregistrando, lo cual es propenso a interbloqueos entre el acceso a sysfs y la eliminación del dispositivo.<br /> <br /> Aborda esto moviendo la eliminación del dispositivo hwmon en acpi_power_meter_notify() fuera del bloqueo en cuestión, pero ten en cuenta que hacerlo solo no es suficiente porque dos notificaciones METER_NOTIFY_CONFIG concurrentes pueden estar intentando eliminar el mismo dispositivo al mismo tiempo. Para evitar que eso suceda, añade un nuevo bloqueo serializando la ejecución de la sentencia switch () en acpi_power_meter_notify(). Para simplificar, es un mutex estático lo cual no debería ser un problema desde la perspectiva del rendimiento.<br /> <br /> El nuevo bloqueo también permite que hwmon_device_register_with_info() en acpi_power_meter_notify() sea llamado fuera del bloqueo interno porque evita que las otras notificaciones manejadas por esa función manipulen el objeto &amp;#39;resource&amp;#39; mientras el dispositivo hwmon basado en él está siendo registrado. El envío de mensajes netlink ACPI desde acpi_power_meter_notify() también es serializado por el nuevo bloqueo, lo cual generalmente ayuda a asegurar que el orden de manejo de las notificaciones de firmware es el mismo que el orden de envío de los mensajes netlink relacionados con ellas.<br /> <br /> Además, ten en cuenta que hwmon_device_register_with_info() puede fallar, en cuyo caso resource-&amp;gt;hwmon_dev se convertirá en un puntero de error, así que añade comprobaciones para evitar intentar desregistrar el dispositivo hwmon al que apunta en ese caso a acpi_power_meter_notify() y acpi_power_meter_remove().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ASoC: amd: corrección de fuga de memoria en las operaciones DMA de pdm acp3x