CVEvulnerability
CVE-2026-31733
5.5 MEDIUM
Official page ↗
- Status
- Analyzed
- Published
- 2026-05-01
- Last modified
- 2026-06-17
- Assigner
- 416baaa9-dc9f-4396-8d5f-8c081fb06d67
- CVSS 3.1 ([email protected])
- 5.5 MEDIUM — CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
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().
Affected configurations
• linux linux kernel (>= 6.12 < 6.12.82)
• linux linux kernel (>= 6.13 < 6.18.22)
• linux linux kernel (>= 6.19 < 6.19.12)
• linux linux kernel 7.0
References
- https://git.kernel.org/stable/c/5e7b2cc8fae9ec2a5bc53311191d2faaff75a4b5 Patch
- https://git.kernel.org/stable/c/7e0ffb72de8aa3b25989c2d980e81b829c577010 Patch
- https://git.kernel.org/stable/c/7ea601daa0153e19cd1c6e6b300348c70c05fe77 Patch
- https://git.kernel.org/stable/c/ca685511f7afd42cdcbb0feea42e5d332d384251 Patch