PT-2026-90234 · Linux · Linux
CVE-2026-89518
·
Published
2026-09-11
·
Updated
2026-09-11
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
sched ext: Fix this rq() 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:
-
scx dsq move() decided whether an rq lock is held by testing this rq()'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.
-
scx bpf sub dispatch() dispatched this rq() with its stashed sub dispatch prev, which is NULL when dispatching for a sibling.
-
finish dispatch(), scx bpf dsq reenq() and scx bpf dsq nr queued() resolved SCX DSQ LOCAL to this CPU's local DSQ rather than the dispatched rq's. The latter two are callable from other rq-locked operations too, where SCX DSQ LOCAL 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 SCX DSQ LOCAL dispatches land on the task's rq.
Use the rq tracked by scx locked rq(), which is set to the dispatched rq
around ops invocations and NULL in unlocked contexts.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux