CVE-2026-89518

What it actually does

A Linux kernel sched_ext bug under SMT/core scheduling lets ops.dispatch() run on a CPU other than the dispatched runqueue. Several BPF kfuncs incorrectly used this_rq() instead of the rq tracked by scx_locked_rq(), causing (1) nested runqueue lock acquisition and potential deadlock in scx_dsq_move(), (2) scx_bpf_sub_dispatch() using a NULL stashed prev task when dispatching for a sibling, and (3) SCX_DSQ_LOCAL resolving to the executing CPU's local DSQ rather than the operation's rq in finish_dispatch(), scx_bpf_dsq_reenq(), and scx_bpf_dsq_nr_queued(). The result is kernel deadlock, hung CPUs, or incorrect task placement on systems using sched_ext. The LOCAL DSQ resolution change also applies without core scheduling (e.g., remote wakeup from ops.enqueue()).

Why it matters to the business

Impact is a host-level denial of service: a locked-up scheduler can freeze the machine and force a reboot, interrupting workloads on any host that runs a sched_ext BPF scheduler with core scheduling enabled. Exploit maturity is none, EPSS is very low (~0.002 and flat over 30 days), the issue is not in KEV, and there is no reported ransomware use, so mass opportunistic exploitation is unlikely. Risk concentrates on Linux hosts that actually load custom sched_ext schedulers; conventional CFS/EEVDF-only fleets are not exposed. No named threat actors or downstream package blast radius are associated with this CVE. Apply kernel updates on a normal patch cycle unless you run sched_ext in production, in which case treat it as a high-availability issue.

How an attack unfolds

This is a local, condition-dependent kernel logic flaw, not a remote code-execution bug. An attacker (or a legitimate but buggy BPF scheduler) needs a system where sched_ext is in use and core scheduling can make dispatch run on a sibling CPU. They load or already run an scx scheduler whose dispatch/kfunc paths call scx_dsq_move, scx_bpf_sub_dispatch, scx_bpf_dsq_reenq, or related helpers. When dispatch targets a sibling runqueue, the kfunc takes the unlocked-context branch, grabs the source rq lock while the dispatched rq lock is already held, and deadlocks the scheduler; alternatively, LOCAL DSQ operations land on the wrong CPU and starve or misplace tasks. There are no public exploits, no KEV listings, and no attributed APT campaigns. Privilege to load sched_ext typically requires CAP_BPF/CAP_SYS_ADMIN or an already-installed custom scheduler, so the realistic path is local DoS on an already-scx host rather than unauthenticated remote attack.

How to fix it

Install a Linux kernel that includes the upstream sched_ext fix 'Fix this_rq() assumptions in dispatch kfuncs' (kfuncs use scx_locked_rq() instead of this_rq() around dispatch). Apply your distribution or vendor kernel update that maps to CVE-2026-89518; if you build in-tree, merge the corresponding sched/ext patch and rebuild. Until patched, avoid loading custom sched_ext schedulers and disable core scheduling on scx hosts if operationally possible. Hosts that never enable CONFIG_SCHED_CLASS_EXT / sched_ext are not affected. Reboot into the patched kernel; the fix is in-kernel and cannot be applied as a userspace-only workaround.

How to confirm the fix worked

Confirm the running kernel changelog or stable commit list includes the sched_ext this_rq()/scx_locked_rq() dispatch kfunc fix for CVE-2026-89518. Check uname -r against your vendor advisory and that CONFIG_SCHED_CLASS_EXT matches your expected config. On scx hosts, after reboot, load the same BPF scheduler under core scheduling and exercise dispatch, DSQ move, reenqueue, and LOCAL DSQ paths; the host should not lock up and tasks should land on the dispatched rq's local DSQ, not the executing CPU's. Review dmesg/journal for new sched_ext warnings or lockdep reports during that test. Systems without sched_ext compiled in can be marked not affected.

Typical attack path

1. Obtain local code execution or admin-equivalent BPF/scheduler control on a Linux host that uses sched_ext.
2. Ensure or wait for core scheduling so dispatch can run on a sibling CPU of the target runqueue.
3. Cause ops.dispatch() (or another rq-locked scx operation) to invoke scx_dsq_move, scx_bpf_sub_dispatch, scx_bpf_dsq_reenq, or SCX_DSQ_LOCAL helpers.
4. Trigger nested rq locking or wrong-CPU LOCAL DSQ resolution.
5. Scheduler deadlocks or tasks are misplaced, producing a hung host that requires reboot.

How to detect it

There are no public exploits or attributed campaigns, so hunting is for accidental or local triggering rather than a known implant. On hosts that run sched_ext, look for sudden multi-CPU hangs, watchdog soft lockups, hung-task timeouts, and lockdep/rq-lock traces mentioning sched_ext, scx_dsq_move, dispatch kfuncs, or kernel/sched/ext.c around the time of a hang. Collect dmesg, journalctl -k, crash dumps, and /proc/sched_debug if the box is still partially responsive. Correlate with who loaded an scx BPF scheduler (bpftool, systemd units, audit CAP_BPF/CAP_SYS_ADMIN). Absence of those schedulers makes exploitation of this CVE implausible. Network IOCs do not apply.

• kernel/sched/ext.c
• scx_dsq_move
• scx_bpf_sub_dispatch
• scx_bpf_dsq_reenq
• scx_bpf_dsq_nr_queued
• scx_locked_rq
• ops.dispatch
• BUG: soft lockup
• watchdog: BUG: soft lockup - CPU
• INFO: task .* blocked for more than
• possible recursive locking detected
• sched_ext

What your security team should do

• Inventory Linux hosts with sched_ext enabled or with scx BPF schedulers loaded; patch those first.
• Apply vendor/upstream kernel updates containing CVE-2026-89518 and reboot.
• Until patched, do not load untrusted or experimental sched_ext schedulers; disable core scheduling on scx hosts if feasible.
• Treat remaining CFS-only kernels as low priority given EPSS ~0.002, no KEV, and no known exploits.
• Add kernel-hung-task/soft-lockup alerting on scx fleets and track this CVE in the normal kernel patch SLA rather than an emergency KEV window.