GPU VulnDB

Database/NVIDIA / GPU stack

Linux kernel nouveau: use-after-free racing the GEM info ioctl against GEM close

UnscoredCVE-2026-89553NVIDIA / GPU stackcurated

Impact

In the non-uvmm path, the GEM info ioctl looked up a VMA without reserving the buffer object, so a concurrent GEM close can free that VMA while the lookup is still using it. Any process holding the DRM render node can drive both sides of the race, which on a shared node means a local user crashing the machine or, with allocator grooming, corrupting freed kernel memory. The practical exposure in a GPU datacenter is limited: nouveau is the open reverse-engineered NVIDIA driver, and production accelerator fleets run the NVIDIA proprietary or open GPU kernel modules instead. It matters for hosts that fell back to nouveau, and for management or head nodes where nouveau binds the onboard display GPU.

Who can reach it

Local, requiring an open file descriptor on a nouveau DRM device (typically /dev/dri/renderD*, which is often group-accessible or exposed into containers). No privilege beyond that is stated in the record.

What to do

Update to a stable kernel containing the fix, which reserves the buffer object around the VMA lookup, and reboot the node. If nouveau is not needed - the usual case on NVIDIA datacenter GPUs - blacklisting the module removes the exposure without a kernel upgrade, though the node still needs a reboot or a module unload for that to take effect. No fixed version is given in the record beyond the four stable commits.

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.