Cloudanix VulnDB

CVE-2026-99085

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A recently fixed Linux kernel bug can freeze the machine when turning off a processor if advanced custom scheduling programs are in use.

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

What it actually does

The sched_ext subsystem fails to re-enqueue tasks held on user DSQs or by the BPF scheduler when a CPU goes offline, and stops calling ops.dispatch() once the CPU is inactive; this leaves the runqueue non-empty so balance_push() never runs on the dying CPU and sched_cpu_wait_empty() hangs indefinitely holding cpu_hotplug_lock.

Why it matters to the business

Systems employing BPF-based schedulers can experience prolonged or permanent stalls during CPU offline operations, degrading availability and requiring watchdog intervention or forced resets; the issue is newly public with negligible exploitation probability and no known ransomware usage.

How an attack unfolds

An attacker with privileges sufficient to load a BPF scheduler and trigger CPU hotplug (or wait for natural offline events) arranges tasks that remain counted on the dying CPU's rq without being pulled; the rq never empties, the hotplug thread blocks, and the offline either hangs or waits for the watchdog to eject the scheduler.

How to fix it

Upgrade to a Linux kernel containing the sched_ext fix that re-enqueues non-local-DSQ tasks on offline rqs and continues ops.dispatch() until SCX_RQ_ONLINE is cleared by the hotplug thread itself.

How to confirm the fix worked

Confirm the running kernel includes the re-enqueue logic on offline rq and the SCX_RQ_ONLINE test change; exercise CPU hot-unplug while a sched_ext scheduler is active and verify the rq empties without watchdog ejection or hung hotplug threads.

Typical attack path

  1. Obtain privileges to load or control a sched_ext BPF scheduler
  2. Create tasks that are either user-DSQ queued or held inside the BPF scheduler and affine only to a target CPU
  3. Trigger or induce CPU offline (hot-unplug, virtualization events, etc.)
  4. Observe the hotplug thread block in sched_cpu_wait_empty() with cpu_hotplug_lock held

How to detect it

Inspect kernel logs for stalled hotplug threads, repeated watchdog-triggered BPF scheduler ejections, and RCU grace-period timeouts during CPU offline; correlate with sched_ext load events.

What your security team should do

  • Prioritize kernel updates on any systems using sched_ext schedulers
  • Temporarily disable custom BPF schedulers on production hosts until patched
  • Add monitoring for hung cpu_down() threads and unexpected BPF scheduler ejections

The record

In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix CPU hotplug hang when a dying CPU's tasks sit in the BPF scheduler A CPU going down has to empty its own rq. Its hotplug thread waits in sched_cpu_wait_empty() until nothing else is left, and the only thing that wakes it is balance_push(), which runs from __schedule() on the dying CPU and pushes off the migratable tasks the CPU picks. sched_ext breaks this. A task sitting on a user DSQ or held by the BPF scheduler is still counted on its rq, but an inactive CPU no longer calls ops.dispatch() and can't pull the task back. The dying CPU goes idle with the task still counted, and one of two things happens: - Another CPU consumes the task. The rq empties without a __schedule() on the dying CPU, so the hotplug thread is never woken and cpu_down() hangs holding cpu_hotplug_lock. - The task is affine only to the dying CPU. Nothing can move it, and the offline stalls until the watchdog ejects the BPF scheduler. When the rq goes offline, re-enqueue every task on it that isn't already on the local DSQ. An enqueue on an offline rq lands on the local DSQ, so the dying CPU itself picks the tasks and balance_push() pushes them off, the same as for the other sched classes. From then on no sched_ext path on another CPU can pull a task off the rq. ops.dispatch() currently stops as soon as the CPU goes inactive, and CPU hotplug then waits for an RCU grace period before taking the rq offline. A BPF-held task affine only to the dying CPU and preempted inside an RCU read-side critical section would block that grace period, and the rq would never go offline. Test SCX_RQ_ONLINE directly so that ops.dispatch() keeps running until the rq goes offline. Only the dying CPU's own hotplug thread clears the flag during teardown, and task_can_run_on_remote_rq() still keeps other rqs' tasks off the CPU.

Affected packages

Ecosystem Package Introduced Fixed