https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 01 Oct 2026 07:46:48 +0000 https://vulnerability.circl.lu/vuln/cve-2026-23371 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>sched/deadline: Fix missing ENQUEUE_REPLENISH during PI de-boosting</p> <p>Running stress-ng --schedpolicy 0 on an RT kernel on a big machine might lead to the following WARNINGs (edited).</p> <p>sched: DL de-boosted task PID 22725: REPLENISH flag missing</p> <p>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 ...</p> <p>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&#39;t already inherit them in the past (shorter deadline than donor&#39;s at that time). This might lead to bandwidth accounting corruption, as enqueue_task_dl() won&#39;t recognize the lock holder as boosted.</p> <p>The scenario occurs when: 1. A DEADLINE task (donor) blocks on a PI mutex held by another DEADLINE task (holder), but the holder doesn&#39;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 do…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>sched/deadline: Fix missing ENQUEUE_REPLENISH during PI de-boosting</p> <p>Running stress-ng --schedpolicy 0 on an RT kernel on a big machine might lead to the following WARNINGs (edited).</p> <p>sched: DL de-boosted task PID 22725: REPLENISH flag missing</p> <p>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 ...</p> <p>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&#39;t already inherit them in the past (shorter deadline than donor&#39;s at that time). This might lead to bandwidth accounting corruption, as enqueue_task_dl() won&#39;t recognize the lock holder as boosted.</p> <p>The scenario occurs when: 1. A DEADLINE task (donor) blocks on a PI mutex held by another DEADLINE task (holder), but the holder doesn&#39;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 do…</p> https://vulnerability.circl.lu/vuln/cve-2026-23371