Cloudanix VulnDB

CVE-2026-99104

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel's advanced task scheduler can leave some running programs stuck after the computer wakes from sleep.

Exploitation
Local Privilege
Attacker needs
High Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Other
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Incorrect propagation of bypass dispatch claims in the sched_ext hierarchy causes descendant schedulers to leak claims or fail to acquire them, leaving tasks stranded on bypass DSQs and triggering WARN_ON_ONCE checks after PM suspend/resume cycles.

Why it matters to the business

Kernel scheduler instability or task starvation can occur on systems using hierarchical sched_ext configurations, especially after suspend/resume, reducing reliability in server and embedded Linux environments.

How an attack unfolds

An attacker with local access enables a sub-scheduler while the system is suspended or manipulates ancestor bypass depth; upon resume the claim state is inconsistent, stranding tasks or firing warnings that can be used for denial of service.

How to fix it

Upgrade the Linux kernel to a version containing the sched_ext bypass claim propagation fix; rebuild and reboot with the corrected scheduler code.

How to confirm the fix worked

Confirm the running kernel contains the fix, then exercise sub-scheduler enable/disable under simulated PM suspend/resume while monitoring for absence of WARN_ON_ONCE and for tasks leaving bypass DSQs.

Typical attack path

  1. Obtain local code execution on a system using sched_ext
  2. Enable a descendant scheduler while an ancestor is in bypass (e.g., during PM suspend)
  3. Trigger or wait for system resume
  4. Observe stranded tasks or kernel warnings indicating claim leakage

How to detect it

Search kernel logs (dmesg, journalctl) for sched_ext bypass claim warnings and inspect scheduler state after suspend/resume cycles; look for tasks remaining on bypass dispatch queues with no consumer.

  • WARN_ON_ONCE.*bypass.*claim
  • tasks sit on the parent's bypass DSQs
  • scx_bypass.*depth

What your security team should do

  • Prioritize kernel updates on all systems using sched_ext within the next maintenance window
  • Add kernel log monitoring for sched_ext bypass-related warnings
  • Test custom scheduler hierarchies for proper suspend/resume behavior after patching

The record

In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix the bypass dispatch claim for schedulers bypassed by an ancestor scx_bypass() claims bypass dispatch when the scheduler's depth goes from zero to one and releases it when the depth returns to zero, but propagates only the depth to the descendants, not the claim. A descendant that starts bypassing with its ancestor never claims, and one whose own bypass ends under the ancestor's keeps its claim, as its depth does not return to zero. A sub-scheduler enable whose bypass ends under a PM suspend thus leaks its claim: the parent keeps hosting bypass dispatch and the sub-scheduler's next bypass trips the WARN_ON_ONCE() on the claim. A sub-scheduler disable that starts under a PM suspend has no claim, so once the resume lifts the root's bypass its tasks sit on the parent's bypass DSQs with nobody consuming them. Claim for every descendant whose depth goes from zero to one in the propagation and release every scheduler in the subtree whose depth returned to zero once the tasks have moved out of the bypass DSQs. A parent that is bypassing itself when a descendant claims consumes only its own bypass DSQs, empty until it leaves bypass and becomes the host.

Affected packages

Ecosystem Package Introduced Fixed