GPU VulnDB

Database/NVIDIA / GPU stack

Linux kernel DRM core: race between failed drm_dev_register() and an open ioctl frees device state in use

CVSS 7.8CVE-2026-89823NVIDIA / GPU stackcurated

Impact

If drm_dev_register() fails part way through - render minor registered, primary minor fails - userspace can already have opened the registered minor and entered a drm_dev_enter() critical section. The unplugged flag was never set, so the ioctl keeps running while the error path tears the device down, giving a use-after-free on DRM device state. This is core DRM code shared by every accelerator driver that registers through it, including amdgpu, so it applies to GPU nodes generally rather than one vendor. The window is narrow and only opens on a failed driver probe, which in practice means a node that is already misbehaving during boot or a driver reload - but a tenant process racing a reprobe on a shared node can turn that into kernel memory corruption. The fix adds drm_dev_synchronize_unplug() to set the flag and drain in-flight readers before cleanup.

Who can reach it

Local user able to open a DRM device node, racing a driver registration that fails - typically during module load or reload. No authentication beyond device access; no remote path.

What to do

Take the stable kernel carrying the drm_dev_synchronize_unplug() fix (five stable commits referenced) and reboot each node; on GPU hosts that means draining jobs first. No fixed release number is given in the record. Nothing to mitigate at runtime other than not reloading GPU driver modules while tenant workloads hold DRM handles.

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.