Linux kernel amdkfd: no TLB flush after MES queue eviction lets in-flight DMA touch unmapped GPU memory

CVSS 8.8CVE-2026-89811NVIDIA / GPU stackcurated

Impact

The MES firmware scheduler, unlike HWS, does not perform heavy-weight TLB invalidation after unmapping compute queues. Without an explicit flush in evict_process_queues_cpsch() and suspend_queues(), in-flight DMA descriptors can still reference memory that has already been unmapped or migrated, so a GPU can access freed or reassigned pages. Observed symptoms are GPU page faults and a hung compute queue during SVM page migration (reproduced on gfx1151 with XNACK enabled) - on a shared AMD GPU node that is a wedged device that usually needs the node drained and the GPU reset, and the memory-access-after-free aspect is what makes it a security issue rather than a hang. The fix adds kfd_flush_tlb() after MES queue removal in both paths.

Who can reach it

Local user with access to the AMD KFD device (/dev/kfd) - any tenant running a ROCm workload on the node. Requires MES-scheduled hardware and queue eviction/suspension (process eviction, debug or CRIU suspend) to occur.

What to do

Update to a stable kernel containing the linked commits (the fix is a cherry-pick of f5c4f88e0f9c) and reboot each AMD GPU node; in practice the amdgpu/amdkfd module cannot be swapped under live ROCm jobs, so drain the node first. A GPU already hung by this needs a reset regardless. No fixed release numbers are given in the record.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-89811 https://git.kernel.org/stable/c/6aae545c87087e4dc96e205452243813bfa73ba2 https://git.kernel.org/stable/c/94e25cb6ab7f4f025bcdcd8ea79fda30f12843a4 https://git.kernel.org/stable/c/e230c546ed93741833ab5babb0b202f9c2052b45

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.