GPU VulnDB

Database/NVIDIA / GPU stack

Linux kernel amdkfd: double-unpin of doorbell/MMIO buffer objects corrupts TTM pin accounting

UnscoredCVE-2026-80618NVIDIA / GPU stackcurated

Impact

amdgpu_amdkfd_gpuvm_free_memory_of_gpu() unpinned DOORBELL and MMIO remap buffer objects before it checked whether the BO was still mapped to the GPU. If the BO is still mapped the call returns -EBUSY and the BO stays alive - but already unpinned - and gets unpinned a second time when the process is torn down, producing a ttm_bo_unpin() refcount underflow. The practical effect on a ROCm node is corrupted pin accounting for a doorbell page that is still GPU-mapped, and a kernel WARN in the kfd_process_wq teardown worker; on a fleet built with panic_on_warn that WARN takes the whole node down and kills every other job on it. Any local user holding /dev/kfd can drive the path with ordinary allocate/map/free calls, so on a multi-tenant MI-series box one tenant reaches it without touching another tenant's API.

Who can reach it

Local user with access to /dev/kfd - that is, any tenant with a ROCm GPU pod or shell on the node. No authentication beyond device access, no root needed.

What to do

Update to a kernel carrying the fix (the change is in the in-tree amdgpu/amdkfd module) and reboot each GPU node, or at minimum stop all ROCm workloads and reload amdgpu, which is a drain in practice because the module cannot be unloaded with jobs holding the device. The record lists stable commits only and names no fixed release - check your distro and ROCm kernel-module errata for the shipping version.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-80618https://git.kernel.org/stable/c/0e27d92f69b8e4c750a4b181cc05a86b9338c4f5https://git.kernel.org/stable/c/1d12ae8b079e173107abec0e5817332954c8e95fhttps://git.kernel.org/stable/c/283e77af49fda96aaa57709fc5408b55ffec075e

Related entries

All NVIDIA / GPU stack entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.