CVE-2026-68094

In the Linux kernel, the following vulnerability has been resolved:

sched_ext: Preserve rq tracking across local DSQ dispatch

dispatch_to_local_dsq() can run from scx_bpf_dsq_move_to_local() while

ops.dispatch() has recorded the current rq. Moving a task to a local DSQ

may switch to the source or destination rq before synchronously invoking

ops.dequeue() through the following path:

SCX_CALL_OP(dispatch, rq)

ops.dispatch()

scx_bpf_dsq_move_to_local()

scx_flush_dispatch_buf()

finish_dispatch()

dispatch_to_local_dsq()

scx_dispatch_enqueue()

local_dsq_post_enq()

call_task_dequeue()

SCX_CALL_OP_TASK(dequeue, locked_rq, ...)

The nested callback saves the recorded rq and restores it on return. If

the rq tracking does not follow the lock switch, update_locked_rq() can

trigger the following lockdep assertion while restoring an rq which is

no longer held:

WARNING: kernel/sched/sched.h:1641 at call_task_dequeue+0x160/0x170

Call Trace:

scx_dispatch_enqueue+0x2b0/0x460

dispatch_to_local_dsq+0x138/0x230

scx_flush_dispatch_buf+0x1af/0x220

scx_bpf_dsq_move_to_local___v2+0xe2/0x1c0

bpf__sched_ext_ops_dispatch+0x4b/0xa7

do_pick_task_scx+0x3b6/0x910

__pick_next_task+0x105/0x1f0

__schedule+0x3e7/0x1980

Introduce switch_rq_lock() to update the tracking state together with

each rq lock handoff. Use it in dispatch_to_local_dsq(),

move_remote_task_to_local_dsq() and the in-balance paths of

scx_dsq_move(), ensuring that scx_locked_rq() consistently refers to the

rq whose lock is actually held throughout the lock dance.