GPU VulnDB

Database/NVIDIA / GPU stack

drm/xe: exec queue destroy after GuC stop leaks GuC IDs and warns on VRAM manager teardown

CVSS 7.8CVE-2025-40166NVIDIA / GPU stackcurated

Impact

In the xe driver for Intel datacenter GPUs, an exec queue is normally disabled and deregistered through the GuC firmware and freed only once the GuC acknowledges. If the driver is unbound while a queue is still running, a later exec_destroy() has no working CT channel to the GuC, the acknowledgement never arrives, and the queue's resources are never released - the dmesg in the record shows the GuC ID manager left unclean and a WARNING in ttm_vram_mgr_fini(). Practical effect is leaked GuC IDs and VRAM manager state on driver teardown, so a node that has had its GPU driver reloaded can be left in a state where GPU memory accounting is wrong until reboot. Exposure is narrow: reaching it requires a driver unbind, which is a root operation, not something a tenant can drive.

Who can reach it

Local and privileged: requires the ability to unbind or unload the xe driver while GPU work is in flight, then a userspace exec-queue destroy. A tenant with only a GPU workload cannot reach this; it is a reliability bug for operators who hot-unbind GPUs for maintenance or VF migration.

What to do

Pick up the stable kernel that checks xe_uc_fw_is_running() and releases exec queue resources directly when the GuC is down (three commits in the record), and reboot nodes running Intel datacenter GPUs on the xe driver. Until then, avoid unbinding the xe driver while workloads hold exec queues - drain the GPU first.

References

https://nvd.nist.gov/vuln/detail/CVE-2025-40166https://git.kernel.org/stable/c/2c6e5904c5bdbac8e0eadee40f70c42bb83f6dc6https://git.kernel.org/stable/c/9f64b3cd051b825de0a2a9f145c8e003200cedd5https://git.kernel.org/stable/c/fa708415566bbe5361c935645107319f8edc8dc1

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.