Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ice: Soluciona la desreferencia de puntero NULL de PTP durante la reconstrucción de VSI<br /> <br /> Soluciona la condición de carrera donde el trabajo periódico de PTP se ejecuta mientras VSI está siendo reconstruido, accediendo a vsi-&amp;gt;rx_rings NULL.<br /> <br /> La secuencia fue:<br /> 1. ice_ptp_prepare_for_reset() cancela el trabajo de PTP<br /> 2. ice_ptp_rebuild() encola inmediatamente el trabajo de PTP<br /> 3. La reconstrucción de VSI ocurre DESPUÉS de ice_ptp_rebuild()<br /> 4. El trabajo de PTP se ejecuta y accede a vsi-&amp;gt;rx_rings NULL<br /> <br /> Corrección: Mantener el trabajo de PTP cancelado durante la reconstrucción, solo encolarlo después de que la reconstrucción de VSI se complete en ice_rebuild().<br /> <br /> Se añadió la función auxiliar ice_ptp_queue_work() para encapsular la lógica de encolamiento del trabajo de PTP, asegurando que solo se encole cuando PTP es compatible y el estado es ICE_PTP_READY.<br /> <br /> Registro de error:<br /> [ 121.392544] ice 0000:60:00.1: Reinicio de PTP exitoso<br /> [ 121.392692] BUG: desreferencia de puntero NULL del kernel, dirección: 0000000000000000<br /> [ 121.392712] #PF: acceso de lectura de supervisor en modo kernel<br /> [ 121.392720] #PF: error_code(0x0000) - página no presente<br /> [ 121.392727] PGD 0<br /> [ 121.392734] Oops: Oops: 0000 [#1] SMP NOPTI<br /> [ 121.392746] CPU: 8 UID: 0 PID: 1005 Comm: ice-ptp-0000:60 Tainted: G S 6.19.0-rc6+ #4 PREEMPT(voluntary)<br /> [ 121.392761] Tainted: [S]=CPU_OUT_OF_SPEC<br /> [ 121.392773] RIP: 0010:ice_ptp_update_cached_phctime+0xbf/0x150 [ice]<br /> [ 121.393042] Traza de Llamada:<br /> [ 121.393047] <br /> [ 121.393055] ice_ptp_periodic_work+0x69/0x180 [ice]<br /> [ 121.393202] kthread_worker_fn+0xa2/0x260<br /> [ 121.393216] ? __pfx_ice_ptp_periodic_work+0x10/0x10 [ice]<br /> [ 121.393359] ? __pfx_kthread_worker_fn+0x10/0x10<br /> [ 121.393371] kthread+0x10d/0x230<br /> [ 121.393382] ? __pfx_kthread+0x10/0x10<br /> [ 121.393393] ret_from_fork+0x273/0x2b0<br /> [ 121.393407] ? __pfx_kthread+0x10/0x10<br /> [ 121.393417] ret_from_fork_asm+0x1a/0x30<br /> [ 121.393432]

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net/sched: cls_u32: usar skb_header_pointer_careful()<br /> <br /> skb_header_pointer() no valida completamente los valores negativos de @offset.<br /> <br /> Usar skb_header_pointer_careful() en su lugar.<br /> <br /> GangMin Kim proporcionó un informe y una reproducción engañando a u32_classify():<br /> <br /> BUG: KASAN: slab-out-of-bounds en u32_classify+0x1180/0x11b0<br /> net/sched/cls_u32.c:221

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> macvlan: arreglar la recuperación de errores en macvlan_common_newlink()<br /> <br /> valis proporcionó una buena reproducción para colapsar el kernel:<br /> <br /> ip link add p1 type veth peer p2<br /> ip link set address 00:00:00:00:00:20 dev p1<br /> ip link set up dev p1<br /> ip link set up dev p2<br /> <br /> ip link add mv0 link p2 type macvlan mode source<br /> ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20<br /> <br /> ping -c1 -I p1 1.2.3.4<br /> <br /> También proporcionó un análisis muy detallado:<br /> <br /> &amp;#39;El problema se activa cuando se crea un nuevo enlace macvlan con el modo MACVLAN_MODE_SOURCE y el parámetro MACVLAN_MACADDR_ADD (o MACVLAN_MACADDR_SET), el dispositivo inferior ya tiene un puerto macvlan y register_netdevice() llamado desde macvlan_common_newlink() falla (por ejemplo, debido al nombre de enlace no válido).<br /> <br /> En este caso, macvlan_hash_add_source es llamado desde macvlan_change_sources() / macvlan_common_newlink():<br /> <br /> Esto añade una referencia a vlan al vlan_source_hash del puerto usando macvlan_source_entry.<br /> <br /> vlan es un puntero a los datos privados del enlace que se está creando.<br /> <br /> Cuando register_netdevice() falla, el error es devuelto desde macvlan_newlink() a rtnl_newlink_create():<br /> <br /> if (ops-&amp;gt;newlink)<br /> err = ops-&amp;gt;newlink(dev, &amp;amp;params, extack);<br /> else<br /> err = register_netdevice(dev);<br /> if (err &amp;lt; 0) {<br /> free_netdev(dev);<br /> goto out;<br /> }<br /> <br /> y se llama a free_netdev(), causando un kvfree() en la estructura net_device que todavía está referenciada en la entrada de origen adjunta al puerto macvlan del dispositivo inferior.<br /> <br /> Ahora, todos los paquetes enviados en el puerto macvlan con una dirección MAC de origen coincidente activarán un uso después de liberación en macvlan_forward_source().&amp;#39;<br /> <br /> Con todo eso, mi solución es asegurarme de que llamamos a macvlan_flush_sources() independientemente del valor de @create cada vez que se toma la ruta "goto destroy_macvlan_port;".<br /> <br /> Muchas gracias a valis por hacer seguimiento de este problema.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> smb/cliente: corrige una fuga de memoria en smb2_open_file()<br /> <br /> Reproductor:<br /> <br /> 1. servidor: los directorios se exportan de solo lectura<br /> 2. cliente: mount -t cifs //${server_ip}/export /mnt<br /> 3. cliente: dd if=/dev/zero of=/mnt/file bs=512 count=1000 oflag=direct<br /> 4. cliente: umount /mnt<br /> 5. cliente: sleep 1<br /> 6. cliente: modprobe -r cifs<br /> <br /> El mensaje de error es el siguiente:<br /> <br /> =============================================================================<br /> BUG cifs_small_rq (No contaminado): Objetos restantes en __kmem_cache_shutdown()<br /> -----------------------------------------------------------------------------<br /> <br /> Object 0x00000000d47521be @offset=14336<br /> ...<br /> ADVERTENCIA: mm/slub.c:1251 en __kmem_cache_shutdown+0x34e/0x440, CPU#0: modprobe/1577<br /> ...<br /> Traza de Llamada:<br /> <br /> kmem_cache_destroy+0x94/0x190<br /> cifs_destroy_request_bufs+0x3e/0x50 [cifs]<br /> cleanup_module+0x4e/0x540 [cifs]<br /> __se_sys_delete_module+0x278/0x400<br /> __x64_sys_delete_module+0x5f/0x70<br /> x64_sys_call+0x2299/0x2ff0<br /> do_syscall_64+0x89/0x350<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> ...<br /> kmem_cache_destroy cifs_small_rq: La caché de slab aún tiene objetos cuando se llama desde cifs_destroy_request_bufs+0x3e/0x50 [cifs]<br /> ADVERTENCIA: mm/slab_common.c:532 en kmem_cache_destroy+0x16b/0x190, CPU#0: modprobe/1577

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ALSA: usb-audio: Prevenir un número excesivo de tramas<br /> <br /> En este caso, el usuario construyó los parámetros con maxpacksize 40 para una tasa de 22050 / pps 1000, y packsize[0] 22 packsize[1] 23. El tamaño del búfer para cada URB de datos es maxpacksize * paquetes, que en este ejemplo es 40 * 6 = 240; Cuando el usuario realiza una operación de escritura para enviar datos de audio al flujo de reproducción ALSA PCM, el número calculado de tramas es packsize[0] * paquetes = 264, lo que excede el tamaño del búfer URB asignado, desencadenando el problema de fuera de límites (OOB) reportado por syzbot [1].<br /> <br /> Se añadió una comprobación para el número de tramas URB de datos individuales al calcular el número de tramas para prevenir [1].<br /> <br /> [1]<br /> BUG: KASAN: slab-out-of-bounds en copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487<br /> Escritura de tamaño 264 en la dirección ffff88804337e800 por la tarea syz.0.17/5506<br /> Traza de Llamada:<br /> copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487<br /> prepare_playback_urb+0x953/0x13d0 sound/usb/pcm.c:1611<br /> prepare_outbound_urb+0x377/0xc50 sound/usb/endpoint.c:333

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> dpaa2-switch: evitar la desreferencia de ZERO_SIZE_PTR cuando num_ifs es cero<br /> <br /> El controlador asigna arreglos para puertos, FDBs y bloques de filtro usando kcalloc() con ethsw-&amp;gt;sw_attr.num_ifs como el recuento de elementos. Cuando el dispositivo reporta cero interfaces (ya sea debido a la configuración del hardware o a problemas de firmware), kcalloc(0, ...) devuelve ZERO_SIZE_PTR (0x10) en lugar de NULL.<br /> <br /> Más tarde en dpaa2_switch_probe(), la inicialización de NAPI accede incondicionalmente a ethsw-&amp;gt;ports[0]-&amp;gt;netdev, lo que intenta desreferenciar ZERO_SIZE_PTR (dirección 0x10), resultando en un pánico del kernel.<br /> <br /> Añadir una verificación para asegurar que num_ifs sea mayor que cero después de recuperar los atributos del dispositivo. Esto evita las asignaciones de tamaño cero y la subsiguiente desreferencia de puntero inválido.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: cpsw_new: Ejecutar la devolución de llamada ndo_set_rx_mode en una cola de trabajo<br /> <br /> El commit 1767bb2d47b7 (&amp;#39;ipv6: mcast: No mantener RTNL para IPV6_ADD_MEMBERSHIP y MCAST_JOIN_GROUP.&amp;#39;) eliminó el bloqueo RTNL para las operaciones IPV6_ADD_MEMBERSHIP y MCAST_JOIN_GROUP. Sin embargo, este cambio desencadenó el siguiente rastreo de llamadas en mi placa BeagleBone Black:<br /> WARNING: net/8021q/vlan_core.c:236 en vlan_for_each+0x120/0x124, CPU#0: rpcbind/496<br /> RTNL: aserción fallida en net/8021q/vlan_core.c (236)<br /> Módulos enlazados:<br /> CPU: 0 UID: 997 PID: 496 Comm: rpcbind No contaminado 6.19.0-rc6-next-20260122-yocto-standard+ #8 PREEMPT<br /> Nombre del hardware: Generic AM33XX (Flattened Device Tree)<br /> Rastreo de llamadas:<br /> unwind_backtrace desde show_stack+0x28/0x2c<br /> show_stack desde dump_stack_lvl+0x30/0x38<br /> dump_stack_lvl desde __warn+0xb8/0x11c<br /> __warn desde warn_slowpath_fmt+0x130/0x194<br /> warn_slowpath_fmt desde vlan_for_each+0x120/0x124<br /> vlan_for_each desde cpsw_add_mc_addr+0x54/0xd8<br /> cpsw_add_mc_addr desde __hw_addr_ref_sync_dev+0xc4/0xec<br /> __hw_addr_ref_sync_dev desde __dev_mc_add+0x78/0x88<br /> __dev_mc_add desde igmp6_group_added+0x84/0xec<br /> igmp6_group_added desde __ipv6_dev_mc_inc+0x1fc/0x2f0<br /> __ipv6_dev_mc_inc desde __ipv6_sock_mc_join+0x124/0x1b4<br /> __ipv6_sock_mc_join desde do_ipv6_setsockopt+0x84c/0x1168<br /> do_ipv6_setsockopt desde ipv6_setsockopt+0x88/0xc8<br /> ipv6_setsockopt desde do_sock_setsockopt+0xe8/0x19c<br /> do_sock_setsockopt desde __sys_setsockopt+0x84/0xac<br /> __sys_setsockopt desde ret_fast_syscall+0x0/0x5<br /> <br /> Este rastreo ocurre porque se llama a vlan_for_each() dentro de cpsw_ndo_set_rx_mode(), que espera que el bloqueo RTNL esté mantenido. Dado que modificar vlan_for_each() para operar sin el bloqueo RTNL no es sencillo, y debido a que ndo_set_rx_mode() se invoca tanto con como sin el bloqueo RTNL a través de diferentes rutas de código, simplemente añadir rtnl_lock() en cpsw_ndo_set_rx_mode() no es una solución viable.<br /> <br /> Para resolver este problema, optamos por ejecutar el procesamiento real dentro de una cola de trabajo, siguiendo el enfoque utilizado por el controlador icssg-prueth.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> spi: tegra210-quad: Proteger curr_xfer en tegra_qspi_combined_seq_xfer<br /> <br /> El campo curr_xfer es leído por el manejador IRQ sin mantener el bloqueo para verificar si una transferencia está en curso. Al limpiar curr_xfer en el bucle de transferencia de secuencia combinada, protegerlo con el spinlock para evitar una condición de carrera con el manejador de interrupciones.<br /> <br /> Proteger la limpieza de curr_xfer en la ruta de salida de tegra_qspi_combined_seq_xfer() con el spinlock para evitar una condición de carrera con el manejador de interrupciones que lee este campo.<br /> <br /> Sin esta protección, el manejador IRQ podría leer un valor curr_xfer parcialmente actualizado, lo que llevaría a una desreferencia de puntero NULL o uso después de liberación.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> linkwatch: usar __dev_put() en las funciones que llaman para prevenir UAF<br /> <br /> Después de que linkwatch_do_dev() llama a __dev_put() para liberar la referencia de linkwatch, el contador de referencias del dispositivo puede bajar a 1. En este punto, netdev_run_todo() puede continuar (ya que linkwatch_sync_dev() ve una lista vacía y regresa sin bloquear), esperar a que el contador de referencias llegue a 1 a través de netdev_wait_allrefs_any(), y luego liberar el dispositivo a través de kobject_put().<br /> <br /> Esto crea un uso después de liberación cuando __linkwatch_run_queue() intenta llamar a netdev_unlock_ops() en el dispositivo ya liberado.<br /> <br /> Tenga en cuenta que añadir el par netdev_lock_ops()/netdev_unlock_ops() en netdev_run_todo() antes de kobject_put() no funcionaría, porque netdev_lock_ops() es condicional - solo bloquea cuando netdev_need_ops_lock() devuelve verdadero. Si el dispositivo no requiere ops_lock, linkwatch no mantendrá ningún bloqueo, y netdev_run_todo() al adquirir el bloqueo no proporcionará sincronización.<br /> <br /> Solucione esto moviendo __dev_put() de linkwatch_do_dev() a sus funciones que llaman. La referencia del dispositivo se empareja lógicamente con la eliminación del dispositivo de la lista, por lo que es razonable que la función que realizó la eliminación de la lista lo libere. Esto permite colocar __dev_put() después de que todos los accesos al dispositivo estén completos, previniendo UAF.<br /> <br /> El error puede reproducirse añadiendo mdelay(2000) después de linkwatch_do_dev() en __linkwatch_run_queue(), luego ejecutando:<br /> <br /> ip tuntap add mode tun name tun_test<br /> ip link set tun_test up<br /> ip link set tun_test carrier off<br /> ip link set tun_test carrier on<br /> sleep 0.5<br /> ip tuntap del mode tun name tun_test<br /> <br /> Informe KASAN:<br /> <br /> ==================================================================<br /> BUG: KASAN: uso después de liberación in netdev_need_ops_lock include/net/netdev_lock.h:33 [inline]<br /> BUG: KASAN: uso después de liberación in netdev_unlock_ops include/net/netdev_lock.h:47 [inline]<br /> BUG: KASAN: uso después de liberación in __linkwatch_run_queue+0x865/0x8a0 net/core/link_watch.c:245<br /> Read of size 8 at addr ffff88804de5c008 by task kworker/u32:10/8123<br /> <br /> CPU: 0 UID: 0 PID: 8123 Comm: kworker/u32:10 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> Workqueue: events_unbound linkwatch_event<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0x156/0x4c9 mm/kasan/report.c:482<br /> kasan_report+0xdf/0x1a0 mm/kasan/report.c:595<br /> netdev_need_ops_lock include/net/netdev_lock.h:33 [inline]<br /> netdev_unlock_ops include/net/netdev_lock.h:47 [inline]<br /> __linkwatch_run_queue+0x865/0x8a0 net/core/link_watch.c:245<br /> linkwatch_event+0x8f/0xc0 net/core/link_watch.c:304<br /> process_one_work+0x9c2/0x1840 kernel/workqueue.c:3257<br /> process_scheduled_works kernel/workqueue.c:3340 [inline]<br /> worker_thread+0x5da/0xe40 kernel/workqueue.c:3421<br /> kthread+0x3b3/0x730 kernel/kthread.c:463<br /> ret_from_fork+0x754/0xaf0 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246<br /> <br /> ==================================================================

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> scsi: target: iscsi: Corrección de uso después de liberación en iscsit_dec_session_usage_count()<br /> <br /> En iscsit_dec_session_usage_count(), la función llama a complete() mientras mantiene el sess-&amp;gt;session_usage_lock. Similar a la lógica de conteo de uso de la conexión, el hilo en espera señalado por complete() (por ejemplo, en la ruta de liberación de la sesión) puede despertar y liberar la estructura iscsit_session inmediatamente.<br /> <br /> Esto crea una condición de carrera donde el hilo actual puede intentar ejecutar spin_unlock_bh() en una estructura de sesión que ya ha sido desasignada, lo que resulta en un KASAN slab-uso después de liberación.<br /> <br /> Para resolver esto, liberar el session_usage_lock antes de llamar a complete() para asegurar que todas las desreferencias del puntero sess hayan terminado antes de que se permita al hilo en espera proceder con la desasignación.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> cgroup/dmem: evitar UAF de pool<br /> <br /> Se observó un problema de UAF:<br /> <br /> ERROR: KASAN: slab-uso después de liberación en page_counter_uncharge+0x65/0x150<br /> Escritura de tamaño 8 en addr ffff888106715440 por la tarea insmod/527<br /> <br /> CPU: 4 UID: 0 PID: 527 Comm: insmod 6.19.0-rc7-next-20260129+ #11<br /> Tainted: [O]=OOT_MODULE<br /> Traza de Llamada:<br /> <br /> dump_stack_lvl+0x82/0xd0<br /> kasan_report+0xca/0x100<br /> kasan_check_range+0x39/0x1c0<br /> page_counter_uncharge+0x65/0x150<br /> dmem_cgroup_uncharge+0x1f/0x260<br /> <br /> Asignado por la tarea 527:<br /> <br /> Liberado por la tarea 0:<br /> <br /> La dirección errónea pertenece al objeto en ffff888106715400<br /> que pertenece a la caché kmalloc-512 de tamaño 512<br /> La dirección errónea está ubicada 64 bytes dentro de<br /> región liberada de 512 bytes [ffff888106715400, ffff888106715600)<br /> <br /> La dirección errónea pertenece a la página física:<br /> <br /> Estado de la memoria alrededor de la dirección errónea:<br /> ffff888106715300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> ffff888106715380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> &amp;gt;ffff888106715400: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ^<br /> ffff888106715480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ffff888106715500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> <br /> El problema ocurre porque un pool aún puede ser retenido por un llamador después de que su región de memoria asociada es desregistrada. La implementación actual libera el pool incluso si los usuarios aún mantienen referencias a él (p. ej., antes de que las operaciones de descarga se completen).<br /> <br /> Este parche añade un contador de referencias a cada pool, asegurando que un pool solo se libera cuando su contador de referencias llega a cero.

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-&amp;gt;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-&amp;gt;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---