CVE-2026-31733

What it actually does

CVE-2026-31733 is a local denial-of-service flaw in the Linux kernel sched_ext subsystem. A stale sched_ext direct-dispatch state value can remain attached to a task after certain enqueue, dequeue, cancellation, scheduler-transition, or deferred-dispatch paths. When that task is later woken and a sched_ext scheduler attempts another direct dispatch, the kernel can hit a WARN_ON_ONCE() condition in the sched_ext dispatch path, with warnings such as failures in scx_dsq_insert_commit(). On systems configured to panic on kernel warnings, this can escalate from a warning into a local system crash or reboot, causing loss of availability. Confidentiality and data integrity are not directly affected.

Why it matters to the business

The primary business risk is interruption of Linux workloads through a local availability failure. Systems using sched_ext or experimental/custom BPF-based scheduling are most relevant; general Linux systems not using sched_ext are less likely to be exposed in practice. Because the issue is not listed in CISA KEV, has no known exploit maturity, and has a very low and flat EPSS score of 0.0013, widespread exploitation is not currently indicated. However, organizations running production workloads on kernels with sched_ext enabled should still treat it as important because a kernel warning can become an outage if panic-on-warn policies are enabled.

How an attack unfolds

An attacker must already have local code execution or the ability to run workloads on an affected Linux host. The attacker then attempts to exercise sched_ext task wakeup, enqueue, dequeue, scheduler transition, or direct-dispatch paths in a way that leaves stale direct-dispatch state on a task. On a later wakeup, when the active sched_ext scheduler calls into the direct dispatch insertion path, the stale state can trigger a kernel warning in the sched_ext code. If the host is configured with kernel.panic_on_warn or similar crash-on-warning behavior, the warning can cause a kernel panic and deny service to all workloads on the machine. Without panic-on-warn, exploitation is more likely to produce kernel warnings, instability signals, and log noise rather than a guaranteed crash.

How to fix it

Apply a Linux kernel update that includes the sched_ext fix clearing ddsp_dsq_id/direct-dispatch state across all relevant direct dispatch, deferred dispatch, enqueue, dequeue, cancellation, and scheduler transition paths. No exact fixed package versions were provided in the input, so use the latest stable kernel release or vendor-supported kernel advisory for the affected distribution. If immediate patching is not possible, reduce exposure by disabling sched_ext where it is not required, avoiding experimental/custom sched_ext schedulers on production systems, restricting local shell/container execution to trusted users, and disabling panic-on-warn behavior where operationally acceptable to prevent warnings from becoming full system outages. Kernel configuration and runtime mitigations should be validated against vendor guidance before production rollout.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version includes the upstream or vendor backport for the sched_ext ddsp_dsq_id stale direct-dispatch-state fix. Validate that the host has been rebooted into the patched kernel, not merely that the package is installed. Review whether sched_ext is enabled and whether any sched_ext scheduler is active. Confirm panic-on-warn settings, such as kernel.panic_on_warn, align with the organization’s availability requirements. After patching, monitor dmesg, journald, syslog, and kernel crash logs for recurrence of sched_ext warnings referencing kernel/sched/ext.c, scx_dsq_insert_commit(), mark_direct_dispatch(), or direct dispatch state. A successful fix should prevent the same sched_ext warning from recurring under normal workload wakeup and scheduler-transition activity.

Typical attack path

1. Obtain local access to an affected Linux system or the ability to run code/workloads on it.
2. Identify that the host is running an affected kernel with sched_ext support and that a sched_ext scheduler is active or can be exercised.
3. Trigger task wakeup and scheduling behavior involving sched_ext direct dispatch, deferred dispatch, enqueue/dequeue fallback, or scheduler transition paths.
4. Cause a task to retain stale direct-dispatch state across one of the affected paths.
5. Trigger a subsequent wakeup/direct-dispatch attempt for the same task.
6. Cause the kernel to emit a sched_ext warning such as a WARN_ON_ONCE() in the dispatch insertion path.
7. If panic-on-warn is enabled, force a kernel panic/reboot and deny service to workloads on the host.

How to detect it

Look for evidence in kernel log sources rather than network telemetry, because exploitation is local and affects scheduler behavior. Relevant sources include dmesg output, journald kernel facility logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dumps, kdump/vmcore records, hypervisor reset events, and endpoint telemetry that records kernel panics or reboots. Search for warnings that reference sched_ext, kernel/sched/ext.c, scx_dsq_insert_commit(), mark_direct_dispatch(), direct dispatch, ddsp_dsq_id, or WARN_ON_ONCE(). Correlate any matching warning with local user sessions, new workload/container starts, BPF or sched_ext scheduler activity, and unexpected reboot or panic events. Because there are no named threat actors, no KEV listing, and no known public exploit maturity in the supplied data, matches should be triaged as suspicious local abuse or workload-triggered kernel instability rather than assumed external compromise.

• WARNING: kernel/sched/ext.c:1273
• scx_dsq_insert_commit
• mark_direct_dispatch
• sched_ext
• ddsp_dsq_id
• direct_dispatch
• process_ddsp_deferred_locals
• dispatch_to_local_dsq
• dequeue_task_scx
• scx_disable_task
• WARN_ON_ONCE
• kernel.panic_on_warn

What your security team should do

• Prioritize patching Linux systems that run sched_ext, custom BPF schedulers, experimental scheduler deployments, high-density compute workloads, or multi-user workloads.
• Inventory systems using affected Linux kernels and determine whether sched_ext is enabled or actively used.
• Apply the latest vendor-supported kernel update that contains the sched_ext direct-dispatch-state clearing fix, then reboot into the patched kernel.
• If patching is delayed, disable sched_ext or avoid loading sched_ext schedulers on production systems where feasible.
• Restrict local code execution and scheduler-control capabilities to trusted administrators and hardened workload identities.
• Review kernel panic policy, especially kernel.panic_on_warn, because this issue is most operationally severe when warnings trigger panics.
• Add detection for sched_ext warning strings in kernel logs, journald, syslog, and crash collection systems.
• Investigate any prior kernel warnings or panics involving scx_dsq_insert_commit(), mark_direct_dispatch(), or kernel/sched/ext.c as possible exploitation or stress-triggered exposure.
• Track vendor advisories for exact fixed versions because no fixed package versions were provided in the vulnerability metadata.
• Because EPSS is low, there is no KEV listing, and no exploit maturity is reported, prioritize based on sched_ext usage and availability criticality rather than broad internet-exploitation urgency.