GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel sched_ext: lock inversion between scx_cgroup_lock and cgroup_mutex deadlocks the node

CVE-2026-74593Kernel, userspace & hypervisorcurated

Impact

scx_cgroup_lock() write-locks scx_cgroup_ops_rwsem before taking cgroup_lock(), which inverts the order used elsewhere and closes a three-way cycle through kernfs: an scx enable/disable waits on cgroup_mutex, a cgroup rmdir waits in kernfs_drain() for an active reference, and a cpu.weight write waits behind the pending rwsem writer. Nothing breaks the cycle. On a Kubernetes GPU node the second and third participants are routine background activity - pod teardown and CPU-share updates from the runtime - so loading or unloading a sched_ext scheduler on a busy node can wedge tasks permanently. Recovery is a reboot, and a GPU node in the middle of a training job is expensive to take out that way.

Who can reach it

Local and privileged: enabling or disabling a sched_ext scheduler requires root on the host. The colliding operations (cgroup removal, cpu.weight writes) come from the container runtime, not from a tenant. Treat this as an operational availability bug on hosts that run sched_ext, not as a tenant-reachable attack.

What to do

Install the patched kernel from the linked stable commits, which take cgroup_lock() first, and reboot each node. Until then the practical mitigation is to avoid enabling or swapping sched_ext schedulers on nodes with live cgroup churn; hosts that never load an scx scheduler do not hit the path.

References

Related entries

All Kernel, userspace & hypervisor 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.