Linux DRM GEM: race between gem_change_handle and gem_close leaves a freed object in the handle table

CVSS 7.8CVE-2026-53145NVIDIA / GPU stackcurated

Impact

The GEM handle-change ioctl races with gem_close on the same DRM file, so a local process with an open render node can get the IDR slot to keep a reference to an object that has already been released, or steal a reference the ioctl inherited. The upstream fix is explicit that three earlier attempts at this race were wrong, and the ioctl is disabled outright in this commit rather than repaired. On a GPU node any tenant process holding /dev/dri/renderD* reaches this path, so on shared nodes a container that is only supposed to submit work gets a use-after-free primitive in the kernel. NVD scores it 7.8 local with high confidentiality, integrity and availability impact; Red Hat tracks it for RHEL 8, 9 and 10.

Who can reach it

Local user or container with an open DRM render node (/dev/dri/renderD*) - no special privilege beyond the device access any GPU workload already has. Not reachable remotely.

What to do

Take the stable kernel containing the fix - it disables DRM_IOCTL_GEM_CHANGE_HANDLE until the race is settled on-list, so applications that call the ioctl will start getting an error rather than a corrupted handle table. No userspace-only mitigation is published. Rolling the fix means drain and reboot each GPU node, or reboot after the distro kernel update; Red Hat has not published fixed RHEL versions in this record.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-53145 https://git.kernel.org/stable/c/1a4f03d22fb655e5f192244fb2c87d8066fcfca2 https://access.redhat.com/security/cve/CVE-2026-53145 https://bugzilla.redhat.com/show_bug.cgi?id=2492773

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.