CVE-2026-31733

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched_ext: Fix stale direct dispatch state in ddsp_dsq_id<br /> <br /> @p-&gt;scx.ddsp_dsq_id can be left set (non-SCX_DSQ_INVALID) triggering a<br /> spurious warning in mark_direct_dispatch() when the next wakeup&amp;#39;s<br /> ops.select_cpu() calls scx_bpf_dsq_insert(), such as:<br /> <br /> WARNING: kernel/sched/ext.c:1273 at scx_dsq_insert_commit+0xcd/0x140<br /> <br /> The root cause is that ddsp_dsq_id was only cleared in dispatch_enqueue(),<br /> which is not reached in all paths that consume or cancel a direct dispatch<br /> verdict.<br /> <br /> Fix it by clearing it at the right places:<br /> <br /> - direct_dispatch(): cache the direct dispatch state in local variables<br /> and clear it before dispatch_enqueue() on the synchronous path. For<br /> the deferred path, the direct dispatch state must remain set until<br /> process_ddsp_deferred_locals() consumes them.<br /> <br /> - process_ddsp_deferred_locals(): cache the dispatch state in local<br /> variables and clear it before calling dispatch_to_local_dsq(), which<br /> may migrate the task to another rq.<br /> <br /> - do_enqueue_task(): clear the dispatch state on the enqueue path<br /> (local/global/bypass fallbacks), where the direct dispatch verdict is<br /> ignored.<br /> <br /> - dequeue_task_scx(): clear the dispatch state after dispatch_dequeue()<br /> to handle both the deferred dispatch cancellation and the holding_cpu<br /> race, covering all cases where a pending direct dispatch is<br /> cancelled.<br /> <br /> - scx_disable_task(): clear the direct dispatch state when<br /> transitioning a task out of the current scheduler. Waking tasks may<br /> have had the direct dispatch state set by the outgoing scheduler&amp;#39;s<br /> ops.select_cpu() and then been queued on a wake_list via<br /> ttwu_queue_wakelist(), when SCX_OPS_ALLOW_QUEUED_WAKEUP is set. Such<br /> tasks are not on the runqueue and are not iterated by scx_bypass(),<br /> so their direct dispatch state won&amp;#39;t be cleared. Without this clear,<br /> any subsequent SCX scheduler that tries to direct dispatch the task<br /> will trigger the WARN_ON_ONCE() in mark_direct_dispatch().