CVE-2026-68094: sched_ext: Preserve rq tracking across local DSQ dispatch

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

schedext: Preserve rq tracking across local DSQ dispatch

dispatchtolocaldsq() can run from scxbpfdsqmovetolocal() 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:

SCXCALLOP(dispatch, rq) ops.dispatch() scxbpfdsqmovetolocal() scxflushdispatchbuf() finishdispatch() dispatchtolocaldsq() scxdispatchenqueue() localdsqpostenq() calltaskdequeue() SCXCALLOPTASK(dequeue, lockedrq, ...)

The nested callback saves the recorded rq and restores it on return. If the rq tracking does not follow the lock switch, updatelockedrq() can trigger the following lockdep assertion while restoring an rq which is no longer held:

WARNING: kernel/sched/sched.h:1641 at calltaskdequeue+0x160/0x170 Call Trace: scxdispatchenqueue+0x2b0/0x460 dispatchtolocaldsq+0x138/0x230 scxflushdispatchbuf+0x1af/0x220 scxbpfdsqmovetolocalv2+0xe2/0x1c0 bpfschedextopsdispatch+0x4b/0xa7 dopicktaskscx+0x3b6/0x910 picknexttask+0x105/0x1f0 schedule+0x3e7/0x1980

Introduce switchrqlock() to update the tracking state together with each rq lock handoff. Use it in dispatchtolocaldsq(), moveremotetasktolocaldsq() and the in-balance paths of scxdsqmove(), ensuring that scxlockedrq() consistently refers to the rq whose lock is actually held throughout the lock dance.