Linux kernel (drivers/gpu/drm/scheduler): When adding reservation-object dependencies to a job, the helper already

Impact

When adding reservation-object dependencies to a job, the helper already consumes the fence reference on failure, so the caller's cleanup drops it a second time - a double free of a dma-fence. Because this sits in the shared DRM scheduler used by amdgpu and xe, one tenant's job submission can corrupt fence objects the whole node's GPU scheduling depends on.

Who can reach it

A tenant process holding /dev/dri/renderD* submits jobs with many buffer-object dependencies while the internal xarray fails to expand - which a tenant induces simply by driving the node into memory pressure from its own container. Applies to any driver on the common DRM scheduler (amdgpu, xe, and others), so this is the mainline datacenter GPU path, not a niche driver.

What to do

Boot a kernel carrying the drm/sched dependency-tracking fix below. Interim: enforce hard per-container memory limits so tenants cannot drive the node into the allocation-failure window, and cap job dependency counts where the userspace stack allows it.

References