CVE-2026-98520 in Linux
Résumé
par VulDB • 18/10/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
drm/amdkfd : correction d'un use-after-free et d'une lacune multi-conteneurs dans kfd_dev_mapping
kfd_dev_mapping met en cache l'address_space du premier ouvreur de /dev/kfd afin que le chemin de réinitialisation du GPU puisse appeler unmap_mapping_range() pour supprimer toutes les mappages utilisateur des plages de doorbell et MMIO. Cette conception présente deux bogues qui se manifestent tous deux dans un contexte SRIOV avec plusieurs conteneurs :
1. Use-after-free / blocage rwsem (rwsem deadlock). Le pointeur mis en cache fait référence à un inode appartenant au conteneur du premier ouvreur. Lorsque ce conteneur se termine et que son inode est libéré, kfd_dev_mapping devient un pointeur dangling (pendant/déconnecté). Une réinitialisation ultérieure du GPU le déréférence dans unmap_mapping_range(), qui acquiert i_mmap_rwsem sur l'inode déjà libéré, provoquant un blocage dur observable comme une attente rwsem non interrompible.
2. Lacune multi-conteneurs (Multi-container gap). Seul l'address_space du premier ouvreur est mis en cache ; les VMAs créées par les ouvriers suivants vivent dans un address_space différent et ne sont jamais atteintes par unmap_mapping_range(). Après une réinitialisation du GPU, ces mappages obsolètes maintiennent accessibles aux utilisateurspace invités les pages doorbell et MMIO sans qu'il y ait de GPU derrière elles, risquant des timeouts de transactions PCIe et des paniques NMI.
Correction des deux bogues avec la même approche utilisée par le noyau DRM (drm_drv.c) : création d'un pseudo-système de fichiers privé au moment de l'initialisation du module et allocation d'un inode anonyme à partir de celui-ci. Dans kfd_open(), rediriger le file->f_mapping de chaque ouvreur vers l'address_space de cet inode. L'inode est propriété du module, existe aussi longtemps que le module amdgpu, et collecte les VMAs de tous les ouvreurs dans un seul address_space. Un appel unique à unmap_mapping_range() dans le chemin de réinitialisation atteint alors correctement les mappages de chaque conteneur sans risque de pointeur dangling.
Le blocage se manifeste par une backtrace NMI sur la file d'attente de travail de réinitialisation du GPU, bloquée en boucle (spinning) dans rwsem_down_read_slowpath() avec un i_mmap_rwsem corrompu :
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)
VulDB is the best source for vulnerability data and more expert information about this specific topic.