CVE-2026-98864 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
sched_ext: Wait for SCX_OPSS_DISPATCHING before reenqueueing a task
ebf1ccff79c4 ("sched_ext: Fix ops.dequeue() semantics") moved the final ops_state store in scx_dispatch_enqueue() after the DSQ unlock so that the custody update and ops.dequeue() precede it. A task can thus be found on a DSQ while still SCX_OPSS_DISPATCHING.
The dequeue and core-sched pick paths wait for the state to clear in ops_dequeue() but the reenqueue paths don't. A reenqueue in that window runs ops.enqueue() and sets SCX_OPSS_QUEUED before the dispatch has completed. The dispatcher's final store then overwrites it with SCX_OPSS_NONE and finish_dispatch() drops every later dispatch of the task.
Wait for SCX_OPSS_DISPATCHING to clear before dequeueing a task for reenqueue, the same way ops_dequeue() does.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel scheduler extension framework introduces significant complexity in managing task states during context switches and scheduling decisions. A recent patch addresses a race condition within the sched_ext subsystem that arises from an ordering issue introduced by commit ebf1ccff79c4, which aimed to fix ops.dequeue() semantics. This earlier change moved the final state store operation in scx_dispatch_enqueue() to occur after releasing the dispatch queue lock. While this adjustment ensures that custody updates and dequeue operations precede the state update, it inadvertently creates a window where a task may appear on a dispatch queue while still holding the SCX_OPSS_DISPATCHING state flag. This temporal gap between logical removal from one scheduling context and full completion of dispatch processing exposes the system to synchronization errors when tasks are requeued for further execution.
The core technical flaw lies in the inconsistency between how different code paths handle task states during transitions. Specifically, while the dequeue path and core-scheduling pick paths correctly wait for the SCX_OPSS_DISPATCHING state to clear before proceeding via ops_dequeue(), the reenqueue paths do not implement this same synchronization mechanism. Consequently, when a task is selected for re-enqueuing within this vulnerable window, it triggers ops.enqueue() and sets its state to SCX_OPSS_QUEUED prematurely. This occurs before the dispatcher has finished processing the previous dispatch operation. The subsequent final store by the dispatcher overwrites the QUEUED state with SCX_OPSS_NONE, effectively nullifying the re-enqueue action. Furthermore, finish_dispatch() subsequently drops any later dispatch attempts for that task because it perceives the task as already processed or in an invalid state relative to its current scheduling context.
This race condition can lead to unpredictable scheduler behavior, including tasks being starved of CPU time despite being logically ready to run, or conversely, tasks executing multiple times unintentionally if the state corruption leads to misinterpretation by subsequent scheduling cycles. In worst-case scenarios involving real-time or latency-sensitive workloads managed through sched_ext, such inconsistencies can result in missed deadlines and degraded system responsiveness. The vulnerability is classified under CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization because it involves a race condition where multiple threads of execution access shared scheduling data structures without adequate locking or state verification to prevent inconsistent updates.
From an offensive security perspective, this flaw aligns with ATT&CK technique T1059.008: Command and Scripting Interpreter via Shell Commands if exploited in conjunction with other vulnerabilities to manipulate process scheduling for evasion purposes, though primarily it represents a stability issue rather than a direct privilege escalation vector. The lack of proper state synchronization allows an attacker who can influence task re-enqueueing logic potentially to disrupt service availability or cause denial-of-service conditions by inducing scheduler loops or dropped dispatches that freeze specific processes.
Mitigation strategies involve applying the upstream kernel patch that enforces waiting for SCX_OPSS_DISPATCHING to clear before allowing a task to be dequeued for re-enqueuing. This aligns the reenqueue logic with the existing safeguards in ops_dequeue(), ensuring consistent state management across all scheduling paths. System administrators should update their Linux kernels to versions containing this fix, particularly those utilizing sched_ext extensions where custom scheduler implementations rely on precise timing and state transitions. Developers integrating sched_ext must ensure that any custom dequeue or enqueue hooks respect these synchronization barriers to prevent similar race conditions in proprietary scheduling logic.