GPU VulnDB

Database/NVIDIA / GPU stack

Linux kernel drm/xe: memory leak when hang replay state is set twice on an exec queue

CVE-2026-74699NVIDIA / GPU stackcurated

Impact

exec_queue_set_hang_replay_state() overwrites q->replay_state without checking whether a buffer from a prior vmemdup_user() is already there, leaking that allocation. A local process holding an xe DRM device node can repeat the call to leak kernel memory until the node is under memory pressure - a denial of service against the whole machine, not just the caller, on a node whose GPUs are shared. This is the Intel Xe driver, so it applies to fleets running Intel datacenter GPUs (Max/Flex series) rather than NVIDIA or AMD parts. The record describes a leak only; there is no claim of corruption or privilege escalation.

Who can reach it

Local user with access to an Intel Xe DRM render node (/dev/dri/renderD*) - which is exactly what a GPU tenant container is given. No special privilege beyond device access is needed.

What to do

Apply the stable fix, which returns an error when q->replay_state is already populated; two stable commits are listed. Deployment is a kernel or DRM-module update - on most distributions that means a new kernel package and a node reboot, with GPU workloads drained first, since the xe module cannot be reloaded while tenant contexts hold the device.

References

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.