CVE-2026-43323

Medium · 5.5

CVSS

5.5

EPSS

0.1%

Published

May 8, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A Linux kernel scheduling problem can make computers freeze or crash when certain programs keep handing over control to each other very quickly.

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

What it actually does

A flaw in Linux kernel fair scheduler zero_vruntime tracking allows leapfrogging between yield() tasks to advance vruntime past overflow without tick or full dequeue updates, violating lag bounds and causing incorrect task eligibility and promotion.

Why it matters to the business

Linux systems running workloads that heavily use sched_yield (or certain stress tools) can experience scheduler instability, leading to hangs, reduced responsiveness, or crashes, especially in containerized or cgroup-heavy environments.

How an attack unfolds

An attacker runs multiple cooperating tasks that repeatedly call yield to force rapid vruntime advancement within a single tick interval; when two or more such tasks are present in the same cgroup or across cgroups that miss timely ticks, the scheduler promotes the wrong task, loses current eligibility, and can trigger the described overflow condition.

How to fix it

Apply the upstream fix that forces a zero_vruntime update at the end of every slice; monitor kernel changelogs for the corrected commit and upgrade to a kernel containing the resolution once released.

How to confirm the fix worked

Boot the patched kernel, run stress-ng --yield or equivalent multi-task yield workloads, and confirm that vruntime values stay within documented lag bounds without triggering the leapfrog scenario.

Typical attack path

Deploy multiple processes that loop on sched_yield
Ensure they remain runnable without blocking or dequeuing
Reach critical execution rate within one scheduler tick
Trigger vruntime overflow and incorrect entity promotion
Induce repeated rescheduling or kernel instability

How to detect it

Review kernel logs for scheduler warnings around vruntime or entity_key, audit process creation and yield patterns in high-CPU workloads, and correlate cgroup tick delivery delays with observed instability.

What your security team should do

Prioritize kernel updates for systems with high sched_yield usage or heavy cgroup activity
Add monitoring for scheduler-related kernel warnings or task starvation symptoms
Limit untrusted code execution on production hosts until patched kernels are deployed

The record

In the Linux kernel, the following vulnerability has been resolved: sched/fair: Fix zero_vruntime tracking fix John reported that stress-ng-yield could make his machine unhappy and managed to bisect it to commit b3d99f43c72b ("sched/fair: Fix zero_vruntime tracking"). The combination of yield and that commit was specific enough to hypothesize the following scenario: Suppose we have 2 runnable tasks, both doing yield. Then one will be eligible and one will not be, because the average position must be in between these two entities. Therefore, the runnable task will be eligible, and be promoted a full slice (all the tasks do is yield after all). This causes it to jump over the other task and now the other task is eligible and current is no longer. So we schedule. Since we are runnable, there is no {de,en}queue. All we have is the __{en,de}queue_entity() from {put_prev,set_next}_task(). But per the fingered commit, those two no longer move zero_vruntime. All that moves zero_vruntime are tick and full {de,en}queue. This means, that if the two tasks playing leapfrog can reach the critical speed to reach the overflow point inside one tick's worth of time, we're up a creek. Additionally, when multiple cgroups are involved, there is no guarantee the tick will in fact hit every cgroup in a timely manner. Statistically speaking it will, but that same statistics does not rule out the possibility of one cgroup not getting a tick for a significant amount of time -- however unlikely. Therefore, just like with the yield() case, force an update at the end of every slice. This ensures the update is never more than a single slice behind and the whole thing is within 2 lag bounds as per the comment on entity_key().

Affected packages

Ecosystem	Package	Introduced	Fixed