CVE-2026-23371
Received Received - Intake
Sched_DEADLINE PI Mutex Priority Change Causes Bandwidth Corruption

Publication date: 2026-03-25

Last updated on: 2026-04-24

Assigner: kernel.org

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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-25
Last Modified
2026-04-24
Generated
2026-05-07
AI Q&A
2026-03-25
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 11 associated CPEs
Vendor Product Version / Range
linux linux_kernel 5.10
linux linux_kernel From 4.19.257 (inc) to 4.20 (exc)
linux linux_kernel From 5.4.212 (inc) to 5.5 (exc)
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel From 5.10.1 (inc) to 6.19.7 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's scheduling system, specifically related to the SCHED_DEADLINE policy and priority inheritance (PI) mutexes. When a task holding a PI mutex is changed from the DEADLINE scheduling class to a lower priority class while still holding the mutex, it may fail to properly inherit scheduling parameters from the task that blocked on it (the donor). This failure causes the kernel to miss setting a critical flag (ENQUEUE_REPLENISH) that is necessary for correct bandwidth accounting.

The issue arises because the lock holder task does not get enqueued with the proper replenishment flag, leading to corrupted bandwidth accounting. This can cause warnings and potential scheduling anomalies on real-time (RT) kernels, especially under stress conditions.

The fix involves introducing a function (__setscheduler_dl_pi()) that detects when a DEADLINE task is moved to a lower priority class and ensures it inherits the correct parameters and sets the ENQUEUE_REPLENISH flag to maintain proper scheduling behavior.


How can this vulnerability impact me? :

This vulnerability can impact systems running real-time Linux kernels using the SCHED_DEADLINE scheduling policy, particularly on large machines under heavy load or stress testing.

The main impact is corrupted bandwidth accounting for tasks holding PI mutexes, which can lead to scheduling warnings and potentially unpredictable task scheduling behavior. This could degrade real-time performance or cause timing issues in critical applications relying on precise scheduling guarantees.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by observing specific WARNING messages in the kernel logs when running certain workloads on a real-time (RT) Linux kernel. For example, running stress-ng with the --schedpolicy 0 option on a big machine might trigger warnings related to the missing ENQUEUE_REPLENISH flag during PI de-boosting.

Look for kernel log messages similar to: "sched: DL de-boosted task PID XXXX: REPLENISH flag missing" and warnings referencing dequeue_task_dl and bandwidth underflow.

Commands to help detect this issue include checking the kernel ring buffer for these warnings using:

  • dmesg | grep -i 'REPLENISH flag missing'
  • journalctl -k | grep -i 'REPLENISH flag missing'
  • Running stress-ng with the --schedpolicy 0 option on an RT kernel to reproduce the condition:
  • stress-ng --schedpolicy 0

What immediate steps should I take to mitigate this vulnerability?

The immediate mitigation is to apply the patch that fixes the missing ENQUEUE_REPLENISH flag during PI de-boosting in the Linux kernel scheduler. This patch introduces a function (__setscheduler_dl_pi()) that ensures proper inheritance of DEADLINE parameters and sets the ENQUEUE_REPLENISH flag when a DEADLINE task is changed to a lower priority class.

Until the patch is applied, avoid scenarios where a SCHED_DEADLINE task holding a PI mutex is changed to a lower priority class via sched_setscheduler() while still holding the mutex, as this triggers the vulnerability.

In practice, this means:

  • Update your Linux kernel to a version that includes the fix for this issue.
  • Avoid changing scheduling policies of DEADLINE tasks holding PI mutexes to lower priority classes until the fix is applied.

Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart