Cloudanix VulnDB

CVE-2026-43392

Medium · 5.5

CVSS

5.5

EPSS

0.1%

Published

May 8, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel scheduler can let busy normal-priority tasks block a special scheduler from turning on, potentially freezing the whole machine.

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

What it actually does

Local fair-class CPU saturation can starve the scx_enable thread during READY-to-ENABLED scheduler class switch, leaving the calling thread unable to complete the transition to the ext class and hanging the system.

Why it matters to the business

Workloads using the sched_ext scheduler can experience indefinite system hangs or unavailability when fair-class tasks saturate the CPU, disrupting operations on affected Linux systems.

How an attack unfolds

An attacker with local access runs CPU-bound fair-class tasks to saturate the runqueue, then invokes scx_enable() (or triggers a path that does so). Because the enable thread now runs at lower priority than fair, it never gets scheduled, preventing the class switch and freezing the system. The original preempt_disable protection was incomplete in partial-switch modes.

How to fix it

Update the Linux kernel to a version containing the upstream fix that offloads scx_enable work to a dedicated SCHED_FIFO kthread. Reboot after installing the updated kernel package. Where live patching is available, apply the vendor's live patch for the starvation condition.

How to confirm the fix worked

Confirm the running kernel contains the scx_enable_cmd kthread and kthread_work changes (check /proc/version or kernel source for the RT helper thread). Attempt to load an scx scheduler under synthetic fair-class load and verify the enable path completes without hang.

Typical attack path

  1. Obtain local code execution on the target host
  2. Launch multiple high-CPU fair-class processes to saturate the scheduler
  3. Trigger sched_ext enable path (via BPF program load or scx_ops registration)
  4. Observe indefinite starvation of the enable thread leading to system hang

How to detect it

Review kernel logs for repeated sched_ext enable attempts that never complete; correlate with high fair-class CPU usage immediately preceding a hang. Examine any crash dumps or hung-task traces that mention scx_enable or sched_class transitions.

What your security team should do

  • Apply the patched kernel as soon as it is available from the distribution
  • Monitor for any downstream packages that ship the vulnerable sched_ext code
  • Test sched_ext workloads under CPU saturation in a lab before production rollout
  • Consider disabling sched_ext on systems where the feature is not required until patched

The record

In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix starvation of scx_enable() under fair-class saturation During scx_enable(), the READY -> ENABLED task switching loop changes the calling thread's sched_class from fair to ext. Since fair has higher priority than ext, saturating fair-class workloads can indefinitely starve the enable thread, hanging the system. This was introduced when the enable path switched from preempt_disable() to scx_bypass() which doesn't protect against fair-class starvation. Note that the original preempt_disable() protection wasn't complete either - in partial switch modes, the calling thread could still be starved after preempt_enable() as it may have been switched to ext class. Fix it by offloading the enable body to a dedicated system-wide RT (SCHED_FIFO) kthread which cannot be starved by either fair or ext class tasks. scx_enable() lazily creates the kthread on first use and passes the ops pointer through a struct scx_enable_cmd containing the kthread_work, then synchronously waits for completion. The workfn runs on a different kthread from sch->helper (which runs disable_work), so it can safely flush disable_work on the error path without deadlock.

Affected packages

Ecosystem Package Introduced Fixed