CVE-2026-99269 in Linux
Summary
by MITRE • 11/03/2026
In the Linux kernel, the following vulnerability has been resolved:
sched_ext: Wait for SCX_OPSS_DISPATCHING before moving tasks off DSQs
A task can be found on a non-local DSQ while the CPU which dispatched it is still running ops.dequeue() and hasn't cleared SCX_OPSS_DISPATCHING. The DSQ consume and move paths don't wait for the dispatch to finish and can operate on the task concurrently with the dispatcher.
Call scx_wait_dispatching() in scx_move_local_task_to_local_dsq(), unlink_dsq_and_switch_rq_lock() and move_task_between_dsqs() before they operate on the task. In scx_move_local_task_to_local_dsq(), wait before scx_resolve_local_dsq() as it may update p->scx.flags.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/03/2026
The Linux kernel scheduler extension subsystem, known as sched_ext, introduces a critical race condition related to task migration and dispatch state management. This vulnerability arises from an inconsistency in how the scheduler handles tasks that are currently being dispatched by one CPU while another CPU attempts to move or consume them from different Dispatch Scheduling Queues (DSQs). Specifically, when a task is placed on a non-local DSQ, there exists a window where the originating CPU may still be executing the ops.dequeue() operation and has not yet cleared the SCX_OPSS_DISPATCHING flag. This flag serves as a synchronization primitive indicating that dispatch operations for this specific task are ongoing. The absence of proper waiting mechanisms in certain code paths allows concurrent access to the task structure, leading to potential data corruption or undefined behavior within the scheduler core logic.
From a technical perspective, the flaw lies in the lack of atomicity and state verification during task movement operations. Functions such as scx_move_local_task_to_local_dsq(), unlink_dsq_and_switch_rq_lock(), and move_task_between_dsqs() were identified as operating on tasks without ensuring that any prior dispatching activity has fully completed. In particular, within scx_move_local_task_to_local_dsq(), the code proceeds to call scx_resolve_local_dsq() which may update internal flags like p->scx.flags before confirming that the previous dispatch state is stable. This premature access violates the expected synchronization protocol for scheduler extensions, where all modifications to task states must be serialized with respect to active dispatcher operations. The race condition effectively allows a consumer CPU to interact with a task structure while it is still being manipulated by the dispatcher CPU, creating a classic time-of-check-to-time-of-use scenario within kernel space memory management and scheduling logic.
The operational impact of this vulnerability can vary depending on system load and scheduler configuration but generally includes potential instability in process execution flow. Since sched_ext allows for custom scheduling policies, bugs here can lead to unpredictable task prioritization, missed deadlines in real-time scenarios, or even kernel panics if the corrupted state leads to invalid memory accesses or infinite loops within the runqueue management code. For systems relying on advanced scheduling features provided by scheduler extensions, this race condition undermines the reliability of process isolation and resource allocation guarantees. It represents a significant risk for environments where precise control over task placement and execution timing is critical, such as high-performance computing clusters or real-time embedded systems utilizing Linux kernel modifications.
To mitigate this vulnerability, the resolution involves inserting explicit synchronization calls to scx_wait_dispatching() before any operation that moves tasks between DSQs or modifies their scheduling state. This ensures that the SCX_OPSS_DISPATCHING flag is cleared and all dispatch-related operations have completed before proceeding with task manipulation. By enforcing this wait condition in the identified functions, the kernel guarantees that no concurrent access occurs during critical sections of scheduler extension logic. From a vulnerability classification standpoint, this issue aligns with CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization, as it involves multiple execution contexts accessing shared data structures without adequate locking or state verification mechanisms. Furthermore, in the context of MITRE ATT&CK techniques for Linux systems, while not directly exploitable by external attackers for immediate privilege escalation, such race conditions can be leveraged in sophisticated attacks to destabilize system services or bypass security controls that rely on predictable scheduling behavior, falling under categories related to resource hijacking or denial of service through kernel instability. System administrators should ensure their kernels are updated with the patch addressing this sched_ext synchronization issue to maintain scheduler integrity and prevent potential exploitation vectors arising from concurrent state corruption.