GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel Xen gntdev: dma-buf export installs the fd before setup, giving a use-after-free

CVSS 7.8CVE-2025-38595Kernel, userspace & hypervisorcurated

Impact

dma_buf_fd() both reserves a descriptor and installs the file, and gntdev's dmabuf_exp_from_pages() kept touching the gntdev_dmabuf object afterwards. Another thread can close the descriptor in that window, running ->release() and destroying the objects the exporting thread is still using - a use-after-free the caller controls the timing of. On a virtualized GPU host this sits in the Xen grant-device path used to share buffers between domains, which is exactly where guest-facing code lives: a guest or local process with the gntdev device can race the close and crash or corrupt the host kernel, and a dom0 compromise means every VM on the box. The fix reorders the operation so the descriptor is reserved first and installed only once everything is set up.

Who can reach it

Local, on a Xen host. A process holding /dev/xen/gntdev that can export a dma-buf and close the returned file descriptor from a second thread. Hosts not running Xen, or with gntdev unavailable to the attacker, are not exposed.

What to do

Update to a stable kernel with commits 3edfd2353f30, 532c8b51b3a8, ba8bc644f168, d59d49af4aee or e59078852604 and reboot each Xen host - which on a hypervisor means evacuating or stopping the guests first, the expensive part of this one. In the meantime, restricting access to /dev/xen/gntdev to the processes that genuinely need it reduces who can reach the race.

References

Related entries

All Kernel, userspace & hypervisor 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.