CVE-2026-89518: sched_ext: Fix this_rq() assumptions in dispatch kfuncs
In the Linux kernel, the following vulnerability has been resolved:
schedext: Fix thisrq() assumptions in dispatch kfuncs
Under core scheduling, dispatch runs from within the core-wide pick and can target a sibling rq, so ops.dispatch() may execute on a CPU different from the dispatched rq's. Several kfunc paths assumed the two always coincide:
- scxdsqmove() decided whether an rq lock is held by testing thisrq()'s rq flags and lock-danced accordingly. A dispatch for a sibling took the unlocked-context branch and acquired the source rq lock on top of the already held dispatched rq lock which could deadlock.
- scxbpfsubdispatch() dispatched thisrq() with its stashed subdispatchprev, which is NULL when dispatching for a sibling.
- finishdispatch(), scxbpfdsqreenq() and scxbpfdsqnrqueued() resolved SCXDSQLOCAL to this CPU's local DSQ rather than the dispatched rq's. The latter two are callable from other rq-locked operations too, where SCXDSQLOCAL now likewise resolves to the op's rq. This changes behavior also without core scheduling, e.g. for ops.enqueue() running a remote wakeup on the waking CPU, and is intended: which CPU happens to execute an operation is incidental, the op's rq is what it is operating on, and the resolution now matches the insert side where SCXDSQLOCAL dispatches land on the task's rq.
Use the rq tracked by scxlockedrq(), which is set to the dispatched rq around ops invocations and NULL in unlocked contexts.
Affected Software
Event History
Frequently Asked Questions
Which deployments are most exposed to the deadlock condition?
Systems using sched_ext with core scheduling are exposed when a dispatch operation targets a sibling runqueue. In that case, the dispatch callback can run on a CPU different from the dispatched runqueue, causing the affected lock-handling path to take an incorrect branch.
What operational symptoms can this issue cause?
The incorrect runqueue-lock assumption can deadlock when the source runqueue lock is acquired while the dispatched runqueue lock is already held. Other affected paths can use a NULL stashed previous task or resolve a local dispatch queue for the executing CPU rather than the operation's runqueue.
Is core scheduling required for every affected behavior?
No. The local-DSQ resolution change also affects cases without core scheduling, including an enqueue operation handling a remote wakeup on the waking CPU. The corrected behavior resolves SCX_DSQ_LOCAL to the operation's runqueue rather than whichever CPU happens to execute the operation.