Cloudanix VulnDB

CVE-2026-98942

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux kernel scheduling bug could let specially crafted programs read invalid memory and cause crashes or leaks on affected systems.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Data Exposure
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition during sched_ext CID table initialization and updates allows concurrent TRACING or SYSCALL programs to read unfilled entries, uninitialized kmalloc memory, or torn topology data before RCU publication.

Why it matters to the business

Linux systems using extended schedulers may experience kernel instability, crashes, or memory disclosure, raising operational risk for latency-sensitive or containerized workloads until patched kernels are deployed.

How an attack unfolds

An attacker loads a BPF tracing or syscall program that races with root scheduler enable, init_cids, or rebuild paths; the program reads global pointers to partially built tables, accessing invalid memory that can be leveraged for further kernel exploitation.

How to fix it

Upgrade to a kernel containing the RCU-private table build and proper kfunc protections described in the fix; rebuild and reboot with the updated kernel; test sched_ext workloads after deployment.

How to confirm the fix worked

Confirm the kernel source contains RCU-protected cid table publication, NULL-checked kfuncs inside RCU read sections, and serialized hotplug handling; run sched_ext enable/disable stress tests with concurrent tracing programs.

Typical attack path

  1. Obtain ability to load BPF programs on target system
  2. Trigger or wait for sched_ext root enable or cid rebuild
  3. Execute concurrent tracing/syscall kfunc that dereferences CID tables
  4. Read uninitialized or torn entries to trigger oops or leak data

How to detect it

Search kernel logs and dmesg for sched_ext warnings, oops, or cid table related faults during scheduler transitions; inspect audit logs for unusual BPF program loads coinciding with scx_root changes.

What your security team should do

  • Prioritize kernel update within standard change windows given low EPSS and no KEV listing
  • Disable sched_ext on systems where the feature is unused
  • Add kernel oops and sched_ext log monitoring to existing alerting

The record

In the Linux kernel, the following vulnerability has been resolved: sched_ext: Build the cid tables privately and publish them with RCU The cid tables are visible to the cid kfuncs while being modified: the first enable publishes the global pointers before filling them, ops.init_cids() overrides rewrite them in place, and re-enables rebuild them in place. A racing TRACING or SYSCALL program can read unfilled entries, including uninitialized memory in the kmalloc'd tables, or torn topo updates. Tie the tables' lifetimes to the root sched instead: each root enable builds a fresh set privately and publishes the per-table __rcu globals once the layout is final, and root disable unpublishes and RCU-frees the set. A non-NULL global is now always a fully built table which stays valid for the reader's RCU read section, and lookups stay two loads. Kfuncs treat NULL as no-mapping, also after the scheduler exits instead of reporting the stale last mapping. The cid kfuncs are available whether the root scheduler is cid-form or cpu-form, the latter to allow gradual migration to cids. Every root therefore builds and publishes a default mapping. Every reader must either be gated on scheduler liveness or NULL-check inside an RCU read section. Fix the two kfuncs that were neither: scx_bpf_this_cid() read the table with no RCU or preemption protection and scx_bpf_task_cid() relied on KF_RCU, which doesn't put a sleepable program in an RCU read section. The hotplug callbacks are instead serialized by retiring the tables inside the cpus_read_lock() section that clears scx_root. v2: Document why every root builds the tables (desc + cid.c comment).

Affected packages

Ecosystem Package Introduced Fixed