---
id: CVE-2026-89518
title: 'sched_ext: Fix this_rq() assumptions in dispatch kfuncs'
summary: |-
  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.dispatc…
severity: medium
cvss: 5.5
cvssVector: 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'
cvssSource: vendor
cwe:
  - CWE-833
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= 4c95380701f58b8112f0b891de8d160e4199e19d <
    6d1890d3c6137ab523799765ae2de62cc05f116d
  - >-
    Linux >= 4c95380701f58b8112f0b891de8d160e4199e19d <
    3dd52416e44a70bc993adb96d2e0d71b9ea21359
  - Linux 6.19
published: '2026-09-11'
updated: '2026-10-19'
sourceUpdated: '2026-10-19T08:48:09.565Z'
source: CVEORG
sourceUrl: 'https://www.cve.org/CVERecord?id=CVE-2026-89518'
references:
  - url: 'https://git.kernel.org/stable/c/6d1890d3c6137ab523799765ae2de62cc05f116d'
  - url: 'https://git.kernel.org/stable/c/3dd52416e44a70bc993adb96d2e0d71b9ea21359'
  - url: >-
      https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-89518.json
  - url: 'https://access.redhat.com/security/cve/CVE-2026-89518'
  - url: 'https://bugzilla.redhat.com/show_bug.cgi?id=2532018'
  - url: 'https://www.cve.org/CVERecord?id=CVE-2026-89518'
  - url: 'https://nvd.nist.gov/vuln/detail/CVE-2026-89518'
  - url: >-
      https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2026/CVE-2026-89518.mbox
tags:
  - cve.org
  - csaf
  - vex
  - red-hat
epss: 0.00198
epssPercentile: 0.09434
ingestedAt: '2026-09-14T11:11:19.887Z'
---

## Overview

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.

## Affected

- `Linux >= 4c95380701f58b8112f0b891de8d160e4199e19d < 6d1890d3c6137ab523799765ae2de62cc05f116d`
- `Linux >= 4c95380701f58b8112f0b891de8d160e4199e19d < 3dd52416e44a70bc993adb96d2e0d71b9ea21359`
- `Linux 6.19`

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.

## Vendor advisories

- **Red Hat VEX** · Moderate · updated 2026-10-17 · [vex](https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-89518.json)