CVE-2026-89518

sched_ext: Fix this_rq() assumptions in dispatch kfuncs

Published Sep 11, 2026 CVSS 3.1 · 4.7 Medium EPSS < 1% KEV · Not listed

Description

In the Linux kernel, the following vulnerability has been resolved:

sched_ext: Fix this_rq() assumptions in dispatch kfuncs

Under core scheduling, dispatch runs from within the core-wide pick and can
target a sibling rq, so ops.dispatch() may execute on a CPU different from
the dispatched rq's. Several kfunc paths assumed the two always coincide:

- scx_dsq_move() decided whether an rq lock is held by testing this_rq()'s
rq flags and lock-danced accordingly. A dispatch for a sibling took the
unlocked-context branch and acquired the source rq lock on top of the
already held dispatched rq lock which could deadlock.

- scx_bpf_sub_dispatch() dispatched this_rq() with its stashed
sub_dispatch_prev, which is NULL when dispatching for a sibling.

- finish_dispatch(), scx_bpf_dsq_reenq() and scx_bpf_dsq_nr_queued()
resolved SCX_DSQ_LOCAL to this CPU's local DSQ rather than the dispatched
rq's. The latter two are callable from other rq-locked operations too,
where SCX_DSQ_LOCAL now likewise resolves to the op's rq. This changes
behavior also without core scheduling, e.g. for ops.enqueue() running a
remote wakeup on the waking CPU, and is intended: which CPU happens to
execute an operation is incidental, the op's rq is what it is operating
on, and the resolution now matches the insert side where SCX_DSQ_LOCAL
dispatches land on the task's rq.

Use the rq tracked by scx_locked_rq(), which is set to the dispatched rq
around ops invocations and NULL in unlocked contexts.

Analysis

Technical impact

The Linux kernel scheduling subsystem contains a flaw where the runqueue returned by this_rq() is assumed to match the runqueue of a dispatched CPU. When dispatch scheduler functions may acquire runqueue locks in the wrong order, causing a deadlock. This can stall the scheduler and render the system unable to schedule new tasks, resulting in a denial of Service condition. The weakness is classified as CWE-833.

Affected Systems

All systems running the Linux kernel without the security update that incorporates commit hashes 3dd52416e44a70bc993adb96d2e0d71b9ea21359 and 6d1890d3c6137ab523799765ae2de62cc05f116d are affected. This includes mainstream distributions, embedded platforms, and any custom kernel build that predates these commits.

Risk and Exploitability

The CVSS score of 4.7 indicates moderate severity. The EPSS score of < 1% suggests a very low probability of exploitation in the wild. The vulnerability is not listed in the CISA KEV‑level privileges or the ability to influence scheduling behavior, as the issue involves internal scheduler lock ordering and dispatcher operations. No public exploits are known, and the EPSS indicates a very low likelihood of exploitation. The likely attack vector would involve manipulating scheduling behavior from privileged context, potentially through a malicious kernel module or other privileged code.

Affected Products

Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).

Vendor Product Default status Versions

Linux

unaffected

Version	Status	Constraints
`4c95380701f58b8112f0b891de8d160e4199e19d`	affected	< 6d1890d3c6137ab523799765ae2de62cc05f116d
`4c95380701f58b8112f0b891de8d160e4199e19d`	affected	< 3dd52416e44a70bc993adb96d2e0d71b9ea21359

Linux

affected

Version	Status	Constraints
`6.19`	affected	—
`0`	unaffected	< 6.19
`7.2.4`	unaffected	≤ 7.2.*
`7.3`	unaffected	≤ *

No data.

Vendor Product Versions

Linux

Linux Kernel

Version	Status	Scheme	Platform
`[4c95380701f58b8112f0b891de8d160e4199e19d,6d1890d3c6137ab523799765ae2de62cc05f116d)`	affected	code_commit	—
`[4c95380701f58b8112f0b891de8d160e4199e19d,3dd52416e44a70bc993adb96d2e0d71b9ea21359)`	affected	code_commit	—

Linux

Linux Kernel

Version	Status	Scheme	Platform
`6.19`	affected	generic	—
`[0,6.19)`	unaffected	generic	—
`[7.2.4,7.3.0)`	unaffected	semver	—
`[7.3-rc1,*]`	unaffected	generic	—

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

Update the kernel to16e44a70bc993adb96d2e0d71b9ea21359 and commit 6d1890d3c6137ab523799765ae2de62cc05f116d, using the distribution’s official security update or the kernel’s authorized repository.
Reboot the host to load the patched kernel and clear any stale scheduling state that could still be present in memory.
After the reboot, monitor the system for scheduler responsiveness and ensure that no debugging options for scheduler events if issues arise.

Generated by OpenCVE AI on September 15, 2026 at 22:19 UTC.

Tracking

Advisories

No advisories available

Metrics

No CVSS v4.0

Attack Vector Local

Attack Complexity High

Privileges Required Low

Scope Unchanged

Confidentiality Impact None

Integrity Impact None

Availability Impact High

User Interaction None

No CVSS v3.0

No CVSS v2

This CVE is not in the KEV list.

Exploit prediction score: < 1% (0.198% probability within 30 days)

Key SSVC decision points have not yet been added.

References

Link	Providers
https://git.kernel.org/stable/c/3dd52416e44a70bc993adb96d2e0d71b9ea21359
https://git.kernel.org/stable/c/6d1890d3c6137ab523799765ae2de62cc05f116d
https://nvd.nist.gov/vuln/detail/CVE-2026-89518
https://www.cve.org/CVERecord?id=CVE-2026-89518

History

Sep 12, 2026 12:15 AM Weaknesses updated. Added references. Scoring metrics updated View changes

Type	Values Removed	Values Added
Weaknesses		CWE-833
References		https://nvd.nist.gov/vuln/detail/CVE-2026-89518 https://www.cve.org/CVERecord?id=CVE-2026-89518
Metrics	threat_severity `None`	cvssV3_1 `{'score': 4.7, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H'}` threat_severity `Moderate`

Sep 11, 2026 11:45 PM Description updated. Title updated. First appearance in the feed. Affected versions updated. Affected vendors updated. Added references View changes

Type	Values Removed	Values Added
Description		In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix this_rq() assumptions in dispatch kfuncs Under core scheduling, dispatch runs from within the core-wide pick and can target a sibling rq, so ops.dispatch() may execute on a CPU different from the dispatched rq's. Several kfunc paths assumed the two always coincide: - scx_dsq_move() decided whether an rq lock is held by testing this_rq()'s rq flags and lock-danced accordingly. A dispatch for a sibling took the unlocked-context branch and acquired the source rq lock on top of the already held dispatched rq lock which could deadlock. - scx_bpf_sub_dispatch() dispatched this_rq() with its stashed sub_dispatch_prev, which is NULL when dispatching for a sibling. - finish_dispatch(), scx_bpf_dsq_reenq() and scx_bpf_dsq_nr_queued() resolved SCX_DSQ_LOCAL to this CPU's local DSQ rather than the dispatched rq's. The latter two are callable from other rq-locked operations too, where SCX_DSQ_LOCAL now likewise resolves to the op's rq. This changes behavior also without core scheduling, e.g. for ops.enqueue() running a remote wakeup on the waking CPU, and is intended: which CPU happens to execute an operation is incidental, the op's rq is what it is operating on, and the resolution now matches the insert side where SCX_DSQ_LOCAL dispatches land on the task's rq. Use the rq tracked by scx_locked_rq(), which is set to the dispatched rq around ops invocations and NULL in unlocked contexts.
Title		sched_ext: Fix this_rq() assumptions in dispatch kfuncs
First Time appeared		Linux Linux linux Kernel
CPEs		cpe:2.3:o:linux:linux_kernel::::::::
Vendors & Products		Linux Linux linux Kernel
References		https://git.kernel.org/stable/c/3dd52416e44a70bc993adb96d2e0d71b9ea21359 https://git.kernel.org/stable/c/6d1890d3c6137ab523799765ae2de62cc05f116d