CVE-2026-74593: sched_ext: Take cgroup_lock() first in scx_cgroup_lock()
In the Linux kernel, the following vulnerability has been resolved:
schedext: Take cgrouplock() first in scxcgrouplock()
scxcgrouplock() write-locks scxcgroupopsrwsem and then takes cgrouplock(), which can deadlock through kernfs:
scx enable/disable cgroup rmdir cpu.weight write ------------------ ------------ ---------------- cgrouplock() percpudownwrite(rwsem) cgrouplock() kernfsgetactive() percpudownread(rwsem) kernfsdrain()
The enable path waits for the rmdir to release cgroupmutex. The rmdir, deactivating the cpu controller's files, waits in kernfsdrain() for the write's active reference. The write, in scxgroupsetweight(), waits for the rwsem behind the pending writer.
Take cgrouplock() first. The set paths take no cgroup locks inside the read side, so a pending write-lock then only waits for read sections that always run to completion, and no dependency from the rwsem back to cgroupmutex remains.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1
Event History
Frequently Asked Questions
What conditions are required to trigger the deadlock?
The deadlock requires concurrent sched_ext enable or disable activity, cgroup removal, and a write to cpu.weight. The described lock cycle involves cgroup_lock(), scx_cgroup_ops_rwsem, and kernfs activity while the CPU controller's files are being deactivated.
What is the operational impact if the issue is triggered?
The involved operations can block each other indefinitely: the sched_ext enable path waits for cgroup removal, cgroup removal waits for kernfs to drain an active cpu.weight write, and that write waits on the sched_ext rwsem.
How does the fix prevent the deadlock?
The fix changes scx_cgroup_lock() to acquire cgroup_lock() before write-locking scx_cgroup_ops_rwsem. This removes the dependency from the rwsem back to cgroup_mutex, while read-side set_* sections can complete without taking cgroup locks.