Cloudanix VulnDB

CVE-2026-99144

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 scheduler can let a program read memory that has already been freed, which may crash the system or allow an attacker with local access to interfere with normal operation.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free read of a destroyed user DSQ structure by a pending deferred reenqueue request that outlives the RCU grace period used to free the DSQ.

Why it matters to the business

Linux systems running sched_ext-enabled kernels can experience kernel crashes, memory corruption, or denial of service; the flaw affects workloads relying on extended scheduling and requires urgent patching to maintain stability.

How an attack unfolds

An attacker with local access crafts scheduler operations that create a user DSQ, queue a request for deferred reenqueue, then destroys the DSQ; the subsequent run_deferred call reads the already-freed DSQ memory after the RCU grace period completes.

How to fix it

Upgrade to a Linux kernel containing the sched_ext fix that cancels pending deferred requests under the per-CPU lock before starting the RCU grace period and that invalidates the DSQ ID atomically.

How to confirm the fix worked

Confirm the kernel source contains the described changes to exit_dsq, run_deferred, and schedule_dsq_reenq that acquire the deferred list lock and check DSQ validity; verify no pending requests reference freed DSQs after grace period.

Typical attack path

  1. Obtain local code execution on a sched_ext-enabled Linux system
  2. Trigger creation and later destruction of a user DSQ via scheduler APIs
  3. Arrange for a request to remain on a per-CPU deferred list
  4. Wait for RCU grace period to free the DSQ while the deferred request still references it
  5. Execute run_deferred to dereference the freed memory

How to detect it

Review kernel logs for sched_ext related oops, use-after-free warnings, or page faults involving DSQ structures; examine scheduler tracepoints around DSQ creation, destruction, and deferred operations for anomalies.

What your security team should do

  • Prioritize kernel updates on all systems using sched_ext
  • Monitor for upstream stable releases containing this sched_ext fix
  • Restrict unprivileged access to scheduler extension interfaces until patched
  • Test patched kernels in staging before broad deployment

The record

In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix use-after-free of a destroyed user DSQ by a deferred reenqueue A deferred reenqueue can read a freed user DSQ. The request stays on its CPU's deferred list until run_deferred() takes it, and the RCU callback that frees the DSQ assumes that the grace period has flushed it, so exit_dsq() checks the per-CPU node without the deferred list lock. A grace period waits for readers in flight, not for a pending run_deferred(). A run_deferred() which starts after the grace period began can detach the request right before the callback looks and then read the freed DSQ's id. Cancel the pending requests before the grace period instead. The irq work that frees the DSQ unlinks every CPU's request under the per-CPU deferred list lock, and schedule_dsq_reenq() ignores a new request under the same lock once the id is invalid. Only a run_deferred() that started before the grace period can hold a request, and it runs with IRQs disabled, so the grace period waits for it and nothing touches the DSQ after the callback.

Affected packages

Ecosystem Package Introduced Fixed