CVE-2026-93150 in Linux
Summary
by MITRE • 09/18/2026
In the Linux kernel, the following vulnerability has been resolved:
cgroup/cpuset: Make nr_deadline_tasks an atomic_t
The nr_deadline_tasks variable in the cpuset structure was introduced by commit 6c24849f5515 ("sched/cpuset: Keep track of SCHED_DEADLINE task in cpusets"). It is reported by sashiko [1] that nr_deadline_tasks
can currently be modified by inc_dl_tasks_cs() under rq->lock and by cpuset_attach() under cpuset_mutex. So if both updates happen simultaneously, the nr_deadline_tasks variable can be corrupted leading to incorrect operations down the road.
Fix that by changing its type to atomic_t so that nr_deadline_tasks are always atomically updated. This fix patch is a low hanging fruit. It can handle some of the races between a concurrent sched_setscheduler() and cpuset_can_attach()/cpuset_attach() calls, but not all of them like the other issue raised by sashiko [2]. This will be handled hopefully
in a future follow up patch.
[1] https://sashiko.dev/#/patchset/20260626181923.133658-1-longman%40redhat.com
[2] https://sashiko.dev/#/patchset/20260630033344.352702-1-longman%40redhat.com
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/18/2026
The Linux kernel's control group subsystem, specifically the cpuset implementation, contained a concurrency vulnerability related to the tracking of SCHED_DEADLINE tasks. The variable nr_deadline_tasks within the cpuset structure is responsible for maintaining an accurate count of tasks operating under the real-time deadline scheduling policy. This counter was originally introduced to ensure proper resource accounting and isolation guarantees when processes are assigned specific CPU sets with strict timing constraints. However, a race condition existed in how this shared state was modified by different kernel execution paths that did not adequately synchronize access to the variable.
The technical flaw stems from concurrent modifications of nr_deadline_tasks under two distinct locking mechanisms. The function inc_dl_tasks_cs modifies the counter while holding rq->lock, which protects runqueue-specific data structures during task scheduling operations such as sched_setscheduler. Simultaneously, cpuset_attach modifies the same variable while holding cpuset_mutex, which governs structural changes to CPU set assignments when tasks are moved between groups. Because these two locks protect different aspects of kernel state and do not provide mutual exclusion for the nr_deadline_tasks counter itself, simultaneous execution can lead to a classic race condition where updates overwrite each other or result in lost increments. This lack of atomicity means that the internal count of deadline-bound tasks may become corrupted, diverging from the actual number of such processes active within the cpuset.
The operational impact of this vulnerability is primarily related to resource accounting accuracy and potential scheduling anomalies. An incorrect value for nr_deadline_tasks can lead to improper enforcement of CPU bandwidth limits or isolation boundaries defined by the cgroup hierarchy. In worst-case scenarios, corrupted counters could cause the kernel to make suboptimal scheduling decisions, potentially leading to priority inversion, missed deadlines for real-time tasks, or even instability in systems relying on strict SCHED_DEADLINE guarantees for critical workloads. While this specific race condition does not directly allow for privilege escalation or remote code execution, it undermines the reliability and predictability of the kernel's resource management subsystems, which is particularly detrimental in environments requiring high availability and deterministic performance characteristics such as industrial control systems or financial trading platforms.
This issue aligns with CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization, commonly known as a race condition. The vulnerability exploits the failure to properly serialize access to shared mutable state across different execution contexts that are protected by unrelated locks. From an ATT&CK perspective, this type of kernel-level concurrency flaw can be leveraged in conjunction with other vulnerabilities for privilege escalation or denial of service attacks against critical infrastructure components that depend on precise resource allocation and isolation guarantees provided by the Linux control group subsystem.
The resolution involves changing the data type of nr_deadline_tasks from a standard integer to an atomic_t, ensuring that all updates are performed atomically without requiring external locking mechanisms specific to this variable. This change eliminates the race condition between inc_dl_tasks_cs and cpuset_attach for this particular counter by leveraging hardware-supported atomic operations. While this fix addresses one aspect of concurrency issues raised in related reports, it is noted as a low-hanging fruit that resolves immediate synchronization problems but does not address all potential races involving sched_setscheduler and cpuset attachment functions. Future patches are expected to handle remaining complex race conditions through more comprehensive locking strategies or structural refactoring of the interaction between scheduler and cgroup subsystems.
System administrators and developers should ensure their Linux kernels are updated with this patch applied, particularly in environments where SCHED_DEADLINE tasks are actively used within cpusets for real-time processing requirements. Monitoring kernel logs for any anomalies related to task scheduling or resource limits may help detect residual issues if other unpatched race conditions exist. The fix represents a standard best practice in systems programming by enforcing atomicity on shared counters that are accessed from multiple execution contexts with different lock scopes, thereby maintaining data integrity and system stability under concurrent load.