CVE-2026-23371: sched/deadline: Fix missing ENQUEUE_REPLENISH during PI de-boosting

In the Linux kernel, the following vulnerability has been resolved:

sched/deadline: Fix missing ENQUEUEREPLENISH 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 dequeuetaskdl+0x15c/0x1f8 ... (runningbw underflow) Call trace: dequeuetaskdl+0x15c/0x1f8 (P) dequeuetask+0x80/0x168 deactivatetask+0x24/0x50 pushdltask+0x264/0x2e0 dltasktimer+0x1b0/0x228 hrtimerrunqueues+0x188/0x378 hrtimerinterrupt+0xfc/0x260 ...

The problem is that when a SCHEDDEADLINE task (lock holder) is changed to a lower priority class via schedsetscheduler(), 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 enqueuetaskdl() 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. schedsetscheduler() 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 ENQUEUEREPLENISH, but this doesn't happen

Fix the issue by introducing setschedulerdlpi(), 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 (pise) and sets ENQUEUEREPLENISH flag to ensure proper bandwidth accounting during the next enqueue operation.