CVE-2026-74593 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
sched_ext: Take cgroup_lock() first in scx_cgroup_lock()
scx_cgroup_lock() write-locks scx_cgroup_ops_rwsem and then takes cgroup_lock(), which can deadlock through kernfs:
scx enable/disable cgroup rmdir cpu.weight write ------------------ ------------ ---------------- cgroup_lock() percpu_down_write(rwsem) cgroup_lock() kernfs_get_active() percpu_down_read(rwsem) kernfs_drain()
The enable path waits for the rmdir to release cgroup_mutex. The rmdir, deactivating the cpu controller's files, waits in kernfs_drain() for the write's active reference. The write, in scx_group_set_weight(), waits for the rwsem behind the pending writer.
Take cgroup_lock() 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 cgroup_mutex remains.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/22/2026
The Linux kernel scheduler extension subsystem contains a concurrency control flaw within the scx_cgroup_lock function that can lead to a deadlock scenario involving resource ordering violations between the cgroup mutex and per-CPU read-write semaphores. This vulnerability arises from an incorrect lock acquisition order where the implementation attempts to write-lock the scx_group_ops_rwsem before acquiring the global cgroup_lock. In concurrent execution environments, this sequence creates a circular dependency chain that prevents progress when multiple kernel threads interact with scheduler extensions and cgroup operations simultaneously. The flaw is particularly insidious because it involves complex interactions between subsystems that manage process groups and CPU weight configurations, requiring precise synchronization to avoid system hangs or unresponsive states during critical resource management tasks.
The operational impact of this vulnerability manifests as a complete deadlock when specific sequences of events occur in parallel. One execution path enables or disables scheduler extensions by acquiring the percpu_down_write on the rwsem while holding no cgroup locks initially, but then attempting to acquire cgroup_lock subsequently. Simultaneously another thread performs a directory removal operation within a cgroup hierarchy which triggers kernfs operations that require cgroup_lock followed by attempts to access kernel file system structures through kernfs_get_active and subsequent waits in kernfs_drain for active references to be released. A third concurrent path involves writing CPU weight parameters via scx_group_set_weight which holds the rwsem write lock but must wait for pending writers while also needing cgroup_lock resources that are held by the directory removal process. This three-way dependency creates a situation where each thread waits indefinitely for a resource held by another, resulting in system instability or complete freeze of affected subsystems without requiring any external input beyond normal administrative operations such as modifying CPU weights or reorganizing container groups.
From a technical classification perspective this vulnerability aligns with CWE-833 which describes deadlock conditions caused by improper lock ordering and synchronization mechanisms that fail to establish consistent acquisition hierarchies across different kernel components. The attack vector falls under MITRE ATT&CK technique T1059 related to command execution through system administration interfaces since exploitation requires legitimate access to modify cgroup configurations or scheduler extension settings rather than remote code execution capabilities. Security practitioners should recognize this as an internal consistency error within the kernel scheduling infrastructure that could be triggered by local users with appropriate privileges to manipulate container resources and CPU accounting parameters, potentially leading to denial of service conditions for all processes running on affected systems without requiring privilege escalation beyond existing administrative rights.
Mitigation strategies focus primarily on applying vendor-provided kernel patches that correct the lock acquisition sequence within scx_cgroup_lock functions across supported Linux distributions. System administrators should ensure timely application of security updates addressing scheduler extension subsystems and monitor system logs for signs of resource contention or hung tasks related to cgroup operations. For environments where immediate patching is not feasible, restricting access to advanced container management tools and CPU weight configuration interfaces can reduce exposure windows until official fixes are deployed. Long-term architectural improvements should involve establishing strict lock ordering protocols across all kernel subsystems that interact with cgroups and scheduler extensions to prevent similar synchronization issues from emerging in future code revisions or custom kernel modifications.