Database/Kernel, userspace & hypervisor
Linux kernel (drivers/gpu/drm/scheduler): When one tenant's scheduler entity is killed, its scheduled fences are not
Impact
When one tenant's scheduler entity is killed, its scheduled fences are not signalled, so any other tenant whose job depends on those fences waits forever. One workload dying - or one attacker deliberately killing processes in a loop - permanently hangs unrelated jobs belonging to different tenants on the same GPU, which is a cross-tenant availability break, not just a local crash.
Who can reach it
An unprivileged process in a container with /dev/dri/renderD* creates cross-process fence dependencies (shared dma-buf / sync_file / syncobj, which is how compositors, media pipelines and multi-process GPU workloads normally work) and then exits or is killed. Lives in the shared drm/scheduler layer, so every scheduler-based driver on the node is affected.
What to do
Update to a kernel containing the fix commits below. Interim: avoid sharing fences/syncobjs across tenant boundaries, and be prepared to reset the GPU (node drain plus device reset) to clear hung dependent jobs.
References
Related entries
- Linux kernel (drivers/gpu/drm/scheduler): Tearing down a GPU scheduler entity takes locks from a fence-signallingCVE-2025-40329 · Linux kernel (drivers/gpu/drm/scheduler)Medium
- Linux kernel (drivers/gpu/drm/scheduler): When a process is killed with GPU work still queued, the scheduler entityCVE-2022-49829 · Linux kernel (drivers/gpu/drm/scheduler)Medium
- Linux kernel (drivers/gpu/drm/scheduler): When adding reservation-object dependencies to a job, the helper alreadyCVE-2025-40096 · Linux kernel (drivers/gpu/drm/scheduler)High
- Linux kernel (drivers/gpu/drm/xe): A batched array of VM_BIND operations could evict other buffer objects belonging toCVE-2025-40086 · Linux kernel (drivers/gpu/drm/xe)Medium
- Intel CPU (MDS / ZombieLoad): Microarchitectural Fill Buffer Data SamplingCVE-2018-12130 · Intel CPU (MDS / ZombieLoad)Medium
- Linux kernel (drivers/pci): Pci_dev_lock() and the sysfs SR-IOV path took the device lock and the config-space accessCVE-2022-49434 · Linux kernel (drivers/pci)Medium
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.