CVE-2026-23371
Description
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.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
A missing ENQUEUE_REPLENISH flag in the Linux kernel's deadline scheduler can cause bandwidth accounting corruption when a DEADLINE task is priority-inheritance de-boosted via sched_setscheduler().
Root
Cause
The vulnerability resides in the Linux kernel's SCHED_DEADLINE scheduler (kernel/sched/deadline.c). When a DEADLINE task that holds a PI mutex is changed to a lower scheduling class via sched_setscheduler(), the kernel may fail to set the ENQUEUE_REPLENISH flag during the subsequent enqueue operation. This occurs if the lock holder did not inherit DEADLINE parameters earlier (e.g., because it already had a shorter deadline than the donor). The missing flag leads to incorrect bandwidth accounting, which can manifest as a running_bw underflow warning and a kernel call trace [1].
Exploitation
Prerequisites
An attacker needs to be able to create and manipulate SCHED_DEADLINE tasks and PI mutexes, which requires sufficient privileges (e.g., capable of creating real-time tasks). The exploit scenario involves three steps: (1) a DEADLINE task (donor) blocks on a PI mutex held by another DEADLINE task (holder); (2) the holder is changed to a lower scheduling class via sched_setscheduler() while still holding the mutex; (3) the holder should inherit DEADLINE parameters from the donor with the ENQUEUE_REPLENISH flag, but this does not occur [1].
Impact
Successful exploitation can cause bandwidth accounting corruption in the deadline scheduler. This may lead to a kernel warning (as shown in the call trace) or, in more severe cases, system instability or denial-of-service conditions. The patch notes indicate that running stress-ng --schedpolicy 0 on an RT kernel can reproduce the warning, suggesting the issue is triggerable under specific workload conditions [1].
Mitigation
The fix introduces the function __setscheduler_dl_pi(), which detects when a DEADLINE task is de-boosted to a lower priority class. It ensures the task inherits the donor's DEADLINE parameters and sets the ENQUEUE_REPLENISH flag for proper bandwidth accounting. The patch has been committed to the Linux kernel stable tree (commit ba1c22924ddcc280672a2a06a9ca99ee3a1b92c3) [1][2]. Users should update to a kernel version containing this fix.
AI Insight generated on May 18, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
10cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*+ 9 more
- cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*range: >=4.19.257,<4.20
- cpe:2.3:o:linux:linux_kernel:5.10:-:*:*:*:*:*:*
- cpe:2.3:o:linux:linux_kernel:7.0:rc1:*:*:*:*:*:*
- cpe:2.3:o:linux:linux_kernel:7.0:rc2:*:*:*:*:*:*
- cpe:2.3:o:linux:linux_kernel:7.0:rc3:*:*:*:*:*:*
- cpe:2.3:o:linux:linux_kernel:7.0:rc4:*:*:*:*:*:*
- cpe:2.3:o:linux:linux_kernel:7.0:rc5:*:*:*:*:*:*
- cpe:2.3:o:linux:linux_kernel:7.0:rc6:*:*:*:*:*:*
- cpe:2.3:o:linux:linux_kernel:7.0:rc7:*:*:*:*:*:*
- (no CPE)
Patches
0No patches discovered yet.
Vulnerability mechanics
AI mechanics synthesis has not run for this CVE yet.
References
2News mentions
0No linked articles in our index yet.