Linux kernel DRM GEM: handle-change race frees a GEM object still referenced by a live handle

CVSS 8.8CVE-2026-63885NVIDIA / GPU stackcurated

Impact

drm_gem_change_handle_ioctl() left the old handle live in the object's IDR between dropping and retaking table_lock. A concurrent GEM_CLOSE on that old handle succeeds in the window, drops handle_count to zero and frees the GEM object while the new handle's IDR entry still points at it - a use-after-free on a GPU buffer object reachable from a process that merely holds a DRM render node. This is DRM core, not one vendor's driver, so it applies to amdgpu, nouveau and the other accelerator drivers that sit on GEM. On a GPU node where tenants get /dev/dri/renderD* into their containers, the floor is a kernel crash that kills every job on the node and the ceiling is kernel memory corruption from a local tenant. The fix NULLs the old IDR entry before releasing table_lock so a racing close sees NULL and returns -EINVAL.

Who can reach it

Local: any process with an open DRM device - in practice any tenant whose pod is handed a render node - racing GEM_HANDLE_CHANGE against GEM_CLOSE. No elevated privilege needed.

What to do

Update to a stable kernel carrying the linked fix and reboot the node; a DRM core fix cannot be applied without replacing the running kernel, and the GPU drivers cannot be unloaded under live workloads. No configuration mitigation short of not exposing DRM render nodes to untrusted workloads. Drain the node before the reboot.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-63885 https://git.kernel.org/stable/c/0dfa42cfe4dbe114533480503934f43e33c1e83d https://git.kernel.org/stable/c/7164d78559b0ff29931a366a840a9e5dd53d4b7c https://git.kernel.org/stable/c/cde2c9257cbe8463b9dcf7b1075177b72b5fd938

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.