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

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