GPU VulnDB

Database/NVIDIA / GPU stack

Linux kernel dma-fence: zero-count dedup returns 1, letting amdgpu user-queue waits read an uninitialized fence

CVSS 7.8CVE-2026-72095NVIDIA / GPU stackcurated

Impact

dma_fence_dedup_array() returned 1 for num_fences == 0 because the loop body never ran and the function returned ++j. The in-tree caller __dma_fence_unwrap_merge() has a zero/one fast path and is safe, but amdgpu_userq_wait_*() can reach the dedup call with a zero local count and then dereference an uninitialized slot in the fence array. On AMD Instinct nodes using user-mode queues, a tenant process issuing a user-queue wait with no fences can get the kernel to follow an uninitialized pointer - a crash that takes the whole node and every colocated GPU job with it, with the usual uninitialized-pointer escalation question open. The fix makes the function return 0 early, matching its documented contract.

Who can reach it

Local user with access to an AMD GPU render node (/dev/dri/renderD*, the amdgpu user-queue wait ioctls). Any tenant with a GPU pod on an amdgpu node qualifies; no privileged capability needed beyond the device file the runtime already injects.

What to do

Take the stable kernel fix and reboot each amdgpu node - the driver cannot be reloaded under live GPU workloads, so this is drain-and-reboot per node. Hosts whose amdgpu builds do not expose user queues are not reachable through the known caller and can follow the normal kernel cadence.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-72095https://git.kernel.org/stable/c/77a9298741f8f9e8b963c977f5582ab21c6d3427https://git.kernel.org/stable/c/7aa8f3dba53422465dbe1be8dbb7240304462bb2https://git.kernel.org/stable/c/e2d9a2ea178a5da0b4a6693e8ebca5c7fc4d7051

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.