CVE-2026-89518

/// Technical description

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

/// Remediation

Check the references section for vendor advisories, patches, and mitigation guidance. If immediate patching is not possible, review the CVSS vector to understand the attack surface and apply compensating controls such as network segmentation or access restrictions.

/// References