CVE-2026-74593: Linux Kernel Race Condition Vulnerability

CVE-2026-74593 Overview

CVE-2026-74593 is a lock-ordering flaw in the Linux kernel's sched_ext (SCX) subsystem. The function scx_cgroup_lock() acquires scx_cgroup_ops_rwsem before taking cgroup_lock(), inverting the ordering used by concurrent cgroup and kernfs paths. Under contention, this creates a three-way deadlock across SCX enable/disable, cgroup rmdir, and cpu.weight writes through kernfs. The issue affects Linux kernel builds that include the extensible scheduler class. Upstream maintainers have resolved the bug by taking cgroup_lock() first inside scx_cgroup_lock(), eliminating the reverse dependency from the rwsem back to cgroup_mutex.

Critical Impact
Local users triggering concurrent SCX scheduler transitions and cgroup operations can deadlock kernel threads, resulting in denial of service on systems using sched_ext.

Affected Products

Linux kernel builds with CONFIG_SCHED_CLASS_EXT enabled
Stable kernel branches referenced by fix commits 2ca6b43, 5f8b696, and a054c9f
Distributions shipping sched_ext-capable kernels

Discovery Timeline

2026-08-22 - CVE-2026-74593 published to NVD
2026-08-23 - Last updated in NVD database

Technical Details for CVE-2026-74593

Vulnerability Analysis

The bug is a classic ABBA lock inversion [CWE-833] between two synchronization primitives used by cgroup infrastructure. scx_cgroup_lock() write-locks the per-cpu rwsem scx_cgroup_ops_rwsem and then attempts to acquire cgroup_lock() (the global cgroup_mutex). Concurrent cgroup paths take these locks in the opposite order, and kernfs drain semantics tie them together into an unbreakable cycle.

Three threads participate in the deadlock. The SCX enable/disable path holds the rwsem write lock and waits for cgroup_mutex. A concurrent cgroup rmdir holds cgroup_mutex and, while deactivating the cpu controller's kernfs files, waits in kernfs_drain() for outstanding active references. A userspace writer to cpu.weight holds a kernfs active reference and, inside scx_group_set_weight(), blocks on percpu_down_read() behind the pending write-lock. Each thread waits on the next, and no forward progress is possible.

Root Cause

The root cause is inconsistent lock acquisition order between scx_cgroup_lock() and the surrounding cgroup/kernfs machinery. Because kernfs drain semantics require in-flight file operations to finish, and those operations themselves take the SCX rwsem for reads, any pending write-lock on the rwsem becomes reachable from cgroup_mutex.

Attack Vector

A local unprivileged or privileged user with the ability to trigger SCX scheduler transitions, remove cgroups, and write to cpu.weight concurrently can reliably provoke the deadlock. Exploitation requires no memory corruption primitives. The result is task hangs on affected kernel threads and loss of availability for scheduling and cgroup management.

No verified proof-of-concept code has been published. Refer to the upstream commits for technical details: Kernel Git Commit 2ca6b43, Kernel Git Commit 5f8b696, and Kernel Git Commit a054c9f.

Detection Methods for CVE-2026-74593

Indicators of Compromise

Kernel hung task warnings referencing scx_cgroup_lock, cgroup_mutex, or kernfs_drain in dmesg.
Blocked tasks in D state with stacks showing percpu_down_write on scx_cgroup_ops_rwsem.
Stalled cgroup rmdir operations and unresponsive writes to cpu.weight under /sys/fs/cgroup.

Detection Strategies

Monitor /proc/*/stack and kernel logs for repeated task hangs correlated with SCX scheduler enable/disable events.
Enable CONFIG_PROVE_LOCKING (lockdep) in test kernels to surface the ABBA ordering during QA.
Correlate cgroup management activity with SCX transitions in host telemetry to identify at-risk workloads.

Monitoring Recommendations

Ingest kernel logs into a centralized data lake and alert on hung_task_timeout_secs warnings referencing SCX or cgroup symbols.
Track uptime, task-state, and scheduler-load metrics on hosts running SCX-based schedulers such as scx_rusty or scx_lavd.
Watch for anomalous processes issuing rapid cgroup create/remove cycles combined with cpu.weight writes.

How to Mitigate CVE-2026-74593

Immediate Actions Required

Upgrade to a Linux kernel that includes fix commits 2ca6b43edf83, 5f8b69642d18, or a054c9ffa9b7.
On production hosts that do not require sched_ext, disable the feature by booting the default scheduler and unloading SCX BPF programs.
Restrict which users and containers can write to cgroup control files and trigger scheduler transitions.

Patch Information

The upstream fix reorders lock acquisition so that scx_cgroup_lock() takes cgroup_lock() before write-locking scx_cgroup_ops_rwsem. Because the set_* paths take no cgroup locks inside the read side, a pending write-lock only waits for read sections that always complete, removing the dependency back to cgroup_mutex. Apply the stable kernel commits referenced above and rebuild or update distribution kernel packages accordingly.

Workarounds

Avoid concurrent SCX enable/disable operations while cgroup rmdir or cpu.weight writes are in flight.
Pin workloads to the default CFS/EEVDF scheduler until patched kernels are deployed.
Limit exposure by ensuring only trusted operators can load SCX BPF schedulers via bpf() and sched_ext sysfs controls.

bash

# Verify running kernel includes the fix commit
uname -r
git -C /usr/src/linux log --oneline | grep -E '2ca6b43|5f8b696|a054c9f'

# Temporarily disable an active sched_ext scheduler
cat /sys/kernel/sched_ext/state
echo 1 > /sys/kernel/sched_ext/ops/disable 2>/dev/null || true