CVE-2026-98864: sched_ext: Wait for SCX_OPSS_DISPATCHING before reenqueueing a task
In the Linux kernel, the following vulnerability has been resolved:
schedext: Wait for SCXOPSSDISPATCHING before reenqueueing a task
ebf1ccff79c4 ("schedext: Fix ops.dequeue() semantics") moved the final opsstate store in scxdispatchenqueue() 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 SCXOPSSDISPATCHING.
The dequeue and core-sched pick paths wait for the state to clear in opsdequeue() but the reenqueue paths don't. A reenqueue in that window runs ops.enqueue() and sets SCXOPSSQUEUED before the dispatch has completed. The dispatcher's final store then overwrites it with SCXOPSSNONE and finishdispatch() drops every later dispatch of the task.
Wait for SCXOPSSDISPATCHING to clear before dequeueing a task for reenqueue, the same way opsdequeue() does.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Before reenqueueing a task, wait for SCX_OPSS_DISPATCHING to clear; ensure the dispatcher's final ops_state store occurs after the DSQ unlock so reenqueue paths wait for dispatch completion.
Event History
Frequently Asked Questions
What race condition is required for this issue to occur?
A task must be found on a dispatch queue while its state is still SCX_OPSS_DISPATCHING, then be dequeued for reenqueue before dispatch completion. The reenqueue path can set SCX_OPSS_QUEUED, after which the dispatcher's final state update can overwrite it with SCX_OPSS_NONE.
What is the resulting scheduling impact?
Once the task state is overwritten with SCX_OPSS_NONE, finish_dispatch() drops every later dispatch of that task. This can prevent subsequent attempts to dispatch the affected task from taking effect.
Is a fix available?
The issue is described as resolved, and stable kernel commit references are provided for the fix. The supplied data does not identify the kernel versions containing those commits.