Linux kernel amdkfd: cached address_space for /dev/kfd causes use-after-free and missed unmap on GPU reset

Impact

amdkfd cached the address_space of the first process to open /dev/kfd and reused it for the GPU reset path, which calls unmap_mapping_range() to revoke doorbell and MMIO mappings. On a node running several containers against one SR-IOV AMD GPU, two things follow. When the first container exits, its inode is freed and the cached pointer dangles; the next GPU reset dereferences it and takes i_mmap_rwsem on freed memory, hanging the amdgpu reset workqueue in an uninterruptible rwsem wait - the GPU never comes back and the node needs a reboot to clear it, not a drain. Second, containers that opened the device later had their VMAs in a different address_space, so a reset never unmapped them: their userspace keeps mapping doorbell and MMIO pages with no GPU behind them, which the kernel log shows as PCIe transaction timeouts and can escalate to an NMI panic. The scored path is a local use-after-free with high confidentiality, integrity and availability impact, so privilege escalation on the GPU node is in play alongside the hang. The fix allocates one module-owned anonymous inode and points every opener at it.

Who can reach it

Local on the GPU node. Any tenant process that can open /dev/kfd - that is, any pod or container with an AMD GPU assigned - participates; no privileges beyond device access are needed. The dangerous state is reached when one such container exits and a GPU reset follows, and under SR-IOV a tenant can provoke a reset with a hanging or faulting kernel.

What to do

Pick up a stable kernel containing the fix (commits 02b74891624e and c3a31087b1c8) and reboot each AMD GPU node; reloading amdgpu is theoretically enough but requires every GPU workload off the node first, so in practice this is a drain-and-reboot per node. There is no runtime mitigation short of restricting /dev/kfd to a single container per GPU, and the advisory names no vendor-supplied userspace workaround.

References

Related entries

• Linux kernel drm/xe: final framebuffer unpin leaves a stale pinned-list entry and risks use-after-freeCVE-2026-98999 · Linux kernel drm/xe (pinned_link bookkeeping on framebuffer unpin)High
• Linux drm/i915: execbuffer relocation cleanup frees past the exec array after command-parser VMAsCVE-2026-99006 · Linux kernel drm/i915 GEM execbuffer (relocation cleanup past the exec array)High
• NVIDIA GPU Display Driver - kernel mode layer (Windows nvlddmkm.sys and Linux nvidia.ko): An out-of-bounds readCVE-2022-28183 · NVIDIA GPU Display Driver - kernel mode layer (Windows nvlddmkm.sys and Linux nvidia.ko)High
• DGX servers BMC: Improper access control on BMCCVE-2022-42275 · DGX servers BMCHigh
• KAI Scheduler: Missing authentication on API endpointsCVE-2026-24177 · KAI SchedulerHigh
• AMD RCCL: unvalidated peer input lets a compromised rank dereference an attacker-controlled pointerCVE-2026-43598 · AMD RCCL (ROCm Communication Collectives Library) peer rank handlingHigh