Linux kernel amdgpu (GEM eviction fence lifetime): amdgpu_gem_object_close() detaches the user-queue eviction fence

CVSS 7.0CVE-2026-99148NVIDIA / GPU stackcurated

Impact

amdgpu_gem_object_close() detaches the user-queue eviction fence from a buffer object before checking bo_va->ref_count, so closing any one handle of a BO drops the fence even while the same file still holds another handle and keeps the GPU mappings. The BO can then be evicted without first suspending that file's user queues, which go on reading and writing through mappings that are only flagged for update - memory the kernel considers free or has handed to something else. On a shared AMD GPU node this is reachable by anything holding a render node, and the outcome is corruption or a hang of the GPU context rather than a clean fault, which usually ends in draining the node. The reporter reproduced it on navi31 with an SDMA user queue and a BO opened twice via GEM_FLINK plus GEM_OPEN. Only relevant where user queues are in use.

Who can reach it

Local user with access to an AMD render node (/dev/dri/renderD*) - any tenant with a GPU container on an AMD node. No special privilege beyond the device node; no remote path.

What to do

Pick up the stable kernel containing the fix (detach the fence only when the last bo_va reference goes away) and reboot the node; a GPU driver module reload is not practical on a node running workloads, so plan a drain and reboot per node. The kernel.org commits are the only published fix references - no distribution fixed version is stated in the record.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-99148 https://git.kernel.org/stable/c/3c44cbcec5eb370713bbd2c315ed7c34d8ccec2b https://git.kernel.org/stable/c/dce8f7f03a47b1744dccf506268f9229b67fab47

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.