CVE-2026-98520 in Linux
Sumário
de VulDB • 18/10/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
drm/amdkfd: corrige use-after-free e lacuna multi-container em kfd_dev_mapping
kfd_dev_mapping armazena em cache o address_space do primeiro abridor de /dev/kfd para que o caminho de reset da GPU possa chamar unmap_mapping_range() para eliminar todos os mapeamentos no espaço do usuário (userspace) das faixas de doorbell e MMIO. Este design possui dois bugs que se manifestam sob SRIOV com múltiplos containers:
1. Use-after-free / deadlock rwsem. O ponteiro em cache refere-se a um inode pertencente ao container do primeiro abridor. Quando esse container é encerrado e seu inode é liberado, kfd_dev_mapping torna-se um pontador dangling (pendurado/inválido). Um reset subsequente da GPU o referencia dentro de unmap_mapping_range(), que adquire i_mmap_rwsem no inode já liberado, causando uma travamento grave observável como uma espera rwsem ininterrupta.
2. Lacuna multi-container. Apenas o address_space do primeiro abridor é armazenado em cache; os VMAs criados por abertura posteriores vivem em um address_space diferente e nunca são alcançados por unmap_mapping_range(). Após um reset da GPU, esses mapeamentos obsoletos mantêm as páginas de doorbell e MMIO acessíveis ao userspace convidado (guest) sem nenhuma GPU atrás delas, arriscando timeouts de transações PCIe e panics NMI.
Corrige ambos os bugs com a mesma abordagem usada pelo DRM core (drm_drv.c): cria um pseudo-sistema de arquivos privado no momento da inicialização do módulo e aloca um inode anônimo a partir dele. Em kfd_open() redireciona o file->f_mapping de cada abridor para o address_space desse inode. O inode é propriedade do módulo, existe exatamente pelo tempo de vida do módulo amdgpu e coleta VMAs de todos os abertura em um único address_space. Uma única chamada unmap_mapping_range() no caminho de reset então alcança corretamente os mapeamentos de cada container sem risco de ponteiro dangling.
O travamento se manifesta como uma backtrace NMI na fila de trabalho de reset da GPU, presa girando (spinning) em rwsem_down_read_slowpath() com um i_mmap_rwsem corrompido:
Workqueue: amdgpu-reset-dev xgpu_ai_mailbox_flr_work [amdgpu]
Call Trace: <TASK> 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)
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.