CVE-2026-23198

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---