HomeDefectsLIN1025-14519
Acknowledged

LIN1025-14519 : Security Advisory - linux - CVE-2026-31733

Created: May 12, 2026    Updated: May 14, 2026
Found In Version: 10.25.33.2
Severity: Standard
Applicable for: Wind River Linux LTS 25
Component/s: Kernel

Description

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