CVE-2026-98520 in Linux
Resumen
por VulDB • 2026-10-18
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
drm/amdkfd: corregir use-after-free y brecha multi-contenedor en kfd_dev_mapping
kfd_dev_mapping almacena en caché address_space del primer usuario que abre /dev/kfd para que la ruta de reinicio de GPU pueda llamar a unmap_mapping_range() para eliminar todos los mapeos de userspace de las rangos de doorbell y MMIO. Este diseño tiene dos errores que se manifiestan bajo SRIOV con múltiples contenedores:
1. Use-after-free / bloqueo rwsem. El puntero almacenado en caché hace referencia a un inode propiedad del contenedor del primer usuario. Cuando ese contenedor sale y su inode es liberado, kfd_dev_mapping se convierte en un puntero colgante (dangling pointer). Un posterior reinicio de GPU lo desreferencia dentro de unmap_mapping_range(), que toma i_mmap_rwsem sobre el inode ya liberado, causando una parada dura observable como una espera rwsem ininterrumpible.
2. Brecha multi-contenedor. Solo se almacena en caché address_space del primer usuario; los VMAs creados por usuarios posteriores viven en un address_space diferente y nunca son alcanzados por unmap_mapping_range(). Después de un reinicio de GPU, esos mapeos obsoletos mantienen accesibles las páginas doorbell y MMIO al userspace invitado sin ninguna GPU detrás, lo que arriesga tiempos de espera de transacciones PCIe y panics NMI.
Corregir ambos errores con el mismo enfoque utilizado por DRM core (drm_drv.c): crear un pseudo-sistema de archivos privado en tiempo de inicialización del módulo y asignar un inode anónimo desde él. En kfd_open() redirigir file->f_mapping de cada usuario a address_space de ese inode. El inode es propiedad del módulo, vive exactamente tanto como el módulo amdgpu, y recopila VMAs de todos los usuarios en un solo address_space. Una única llamada a unmap_mapping_range() en la ruta de reinicio entonces alcanza correctamente los mapeos de cada contenedor sin riesgo de puntero colgante.
La parada se manifiesta como una traza NMI en el workqueue de reinicio de GPU atascado girando en rwsem_down_read_slowpath() con un i_mmap_rwsem corrupto:
Workqueue: amdgpu-reset-dev xgpu_ai_mailbox_flr_work [amdgpu]
Call Trace: kvm_wait+0x1f/0x40 __pv_queued_spin_lock_slowpath+0x31d/0x3a0 _raw_spin_lock_irq+0x51/0x80 rwsem_down_read_slowpath+0xb3/0x550 down_read+0x48/0xd0 unmap_mapping_range+0x71/0x140 kfd_dev_unmap_mapping_range+0x5b/0x140 [amdgpu]
amdgpu_amdkfd_clear_kfd_mapping+0xd8/0x190 [amdgpu]
amdgpu_device_gpu_recover+0x232/0x450 [amdgpu]
xgpu_ai_mailbox_flr_work+0xb5/0xc0 [amdgpu]
process_one_work+0x18e/0x3e0 worker_thread+0x2e3/0x420 kthread+0x10a/0x230
(cherry picked from commit 1128b4a52de1572e87431de837fd9850cb99542c)
If you want to get best quality of vulnerability data, you may have to visit VulDB.