Linux kernel (drivers/gpu/drm/scheduler): Tearing down a GPU scheduler entity takes locks from a fence-signalling

CVSS 6.0CVE-2025-40329Kernel, userspace & hypervisorcurated

Impact

Tearing down a GPU scheduler entity takes locks from a fence-signalling callback that runs in interrupt context, so a tenant whose jobs carry cross-fence dependencies can wedge the CPU that is signalling and the shared GPU scheduler behind it. This is a whole-node outage vector: the scheduler is shared by every tenant on the device, and a deadlock there stalls all of their queues, not just the attacker's.

Who can reach it

An unprivileged process in a container holding /dev/dri/renderD* reaches this by submitting jobs with dependencies on other fences and then dying or being killed, which is exactly what a crashing or OOM-killed workload does. The code is in the shared drm/scheduler layer, so amdgpu, xe, nouveau, panfrost and every other scheduler user is affected, not one vendor.

What to do

Update to a kernel with the fix commits below, which moves the dependency re-arming out of the fence callback into a work item. No interim control short of removing GPU access; the trigger is normal process teardown.

References

https://git.kernel.org/stable/c/70150b9443dddf02157d821c68abf438f55a2e8e https://git.kernel.org/stable/c/0d63031ee4a57be0252cb9a4e09ae921c75cece9 https://nvd.nist.gov/vuln/detail/CVE-2025-40329

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.