Cloudanix VulnDB

CVE-2026-23371

Medium · 5.5

CVSS

5.5

EPSS

0.2%

Published

Mar 25, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A scheduling bug in Linux can cause warnings or instability on systems that run certain real-time tasks while they hold locks.

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
Low

What it actually does

Missing ENQUEUE_REPLENISH flag during PI de-boosting of SCHED_DEADLINE tasks after sched_setscheduler() to a lower class causes bandwidth accounting corruption and running_bw underflow in the deadline scheduler.

Why it matters to the business

Linux systems running real-time workloads may experience scheduler warnings, instability, or reduced availability under concurrent scheduling and locking stress, with increased urgency due to 215 days of public exposure and rising EPSS trend.

How an attack unfolds

A local attacker runs processes that create a SCHED_DEADLINE donor blocking on a PI mutex held by another DEADLINE task, then uses sched_setscheduler to downgrade the holder while the mutex is held, bypassing the new inheritance path that sets ENQUEUE_REPLENISH and triggering accounting corruption.

How to fix it

Upgrade the Linux kernel to a version containing the __setscheduler_dl_pi fix; rebuild and reboot with the patched kernel; test real-time scheduling workloads after upgrade.

How to confirm the fix worked

Run stress-ng --schedpolicy 0 on an RT kernel and confirm absence of 'REPLENISH flag missing' and 'running_bw underflow' warnings in dmesg; verify the patched __setscheduler_dl_pi path is present via kernel source inspection or symbols.

Typical attack path

  1. Obtain local execution on a Linux system with RT kernel
  2. Create SCHED_DEADLINE task holding PI mutex with another DEADLINE donor blocked
  3. Invoke sched_setscheduler to change holder to lower class while mutex held
  4. Trigger dl_task_timer or push_dl_task paths that expose missing REPLENISH flag
  5. Observe bandwidth underflow or kernel WARNING

How to detect it

Search kernel logs (dmesg, journalctl) for scheduler warnings referencing deadline.c, dequeue_task_dl, REPLENISH flag, or running_bw underflow; correlate with processes using sched_setscheduler and PI mutexes.

  • REPLENISH flag missing
  • running_bw underflow
  • dequeue_task_dl+0x15c
  • dl_task_timer

What your security team should do

  • Prioritize kernel upgrade on all systems using SCHED_DEADLINE or RT scheduling
  • Restrict unprivileged use of sched_setscheduler and real-time policies via ulimit or systemd settings
  • Enable kernel logging and alerting for scheduler warnings
  • Monitor EPSS trend and re-evaluate exploit maturity

The record

In the Linux kernel, the following vulnerability has been resolved: sched/deadline: Fix missing ENQUEUE_REPLENISH during PI de-boosting Running stress-ng --schedpolicy 0 on an RT kernel on a big machine might lead to the following WARNINGs (edited). sched: DL de-boosted task PID 22725: REPLENISH flag missing WARNING: CPU: 93 PID: 0 at kernel/sched/deadline.c:239 dequeue_task_dl+0x15c/0x1f8 ... (running_bw underflow) Call trace: dequeue_task_dl+0x15c/0x1f8 (P) dequeue_task+0x80/0x168 deactivate_task+0x24/0x50 push_dl_task+0x264/0x2e0 dl_task_timer+0x1b0/0x228 __hrtimer_run_queues+0x188/0x378 hrtimer_interrupt+0xfc/0x260 ... The problem is that when a SCHED_DEADLINE task (lock holder) is changed to a lower priority class via sched_setscheduler(), it may fail to properly inherit the parameters of potential DEADLINE donors if it didn't already inherit them in the past (shorter deadline than donor's at that time). This might lead to bandwidth accounting corruption, as enqueue_task_dl() won't recognize the lock holder as boosted. The scenario occurs when: 1. A DEADLINE task (donor) blocks on a PI mutex held by another DEADLINE task (holder), but the holder doesn't inherit parameters (e.g., it already has a shorter deadline) 2. sched_setscheduler() changes the holder from DEADLINE to a lower class while still holding the mutex 3. The holder should now inherit DEADLINE parameters from the donor and be enqueued with ENQUEUE_REPLENISH, but this doesn't happen Fix the issue by introducing __setscheduler_dl_pi(), which detects when a DEADLINE (proper or boosted) task gets setscheduled to a lower priority class. In case, the function makes the task inherit DEADLINE parameters of the donoer (pi_se) and sets ENQUEUE_REPLENISH flag to ensure proper bandwidth accounting during the next enqueue operation.

Affected packages

Ecosystem Package Introduced Fixed