Back to CVE records
Medium 5.5Published May 1, 2026

CVE-2026-31733sched_ext: Fix stale direct dispatch state in ddsp_dsq_id

Updated under an hour ago ()

Does this affect you?

It affects Linux and 1 other product. Add what you run to find out whether that includes you.

No exploitation reported and no EPSS estimate yet.

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().

CVSS
5.5 MEDIUM (v3.1, NVD)CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Weakness (CWE)
Not given
Known exploited
Not in CISA's KEV catalog
EPSS (exploitation in the next 30 days)
Not loaded for this CVE
Assigned by
Linux
NVD analysis
Analyzed
Record last updated
May 11, 2026
First seen by InfoSec Signals
Oct 9, 2026

Affected products

Affected products
Linux Linux
linux:linux (from the name)
from 5b26f7b920f76b2b9cc398c252a9e35e44bf5bb9 before ca685511f7afd42cdcbb0feea42e5d332d384251; from 5b26f7b920f76b2b9cc398c252a9e35e44bf5bb9 before 5e7b2cc8fae9ec2a5bc53311191d2faaff75a4b5; from 5b26f7b920f76b2b9cc398c252a9e35e44bf5bb9 before 7ea601daa0153e19cd1c6e6b300348c70c05fe77; from 5b26f7b920f76b2b9cc398c252a9e35e44bf5bb9 before 7e0ffb72de8aa3b25989c2d980e81b829c577010
CNA record
linux linux_kernel
linux:linux_kernel
from 6.12 before 6.12.82; from 6.13 before 6.18.22; from 6.19 before 6.19.12; 7.0; 7.0; 7.0; 7.0; 7.0; and 1 more ranges
NVD

References

References

The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.

Your cookie choices
We use essential cookies to run this site, and, only with your consent, an advertising cookie from Google to measure whether our ads lead to sign-ups and subscriptions. See our for details.