CVE-2026-23371 in Linux
Riassunto
di VulDB • 16/06/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
sched/deadline: Correzione della mancanza di ENQUEUE_REPLENISH durante il de-boosting tramite PI (Priority Inheritance)
L'esecuzione di stress-ng --schedpolicy 0 su un kernel RT (Real-Time) su una macchina di grandi dimensioni potrebbe generare i seguenti avvisi (modificati).
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 ...
Il problema consiste nel fatto che quando un task SCHED_DEADLINE (lock holder) viene modificato verso una classe di priorità inferiore tramite sched_setscheduler(), potrebbe non riuscire a ereditare correttamente i parametri dei potenziali donatori DEADLINE se non li aveva già ereditati in precedenza (ad esempio, se aveva una deadline più breve rispetto a quella del donatore in quel momento). Ciò potrebbe portare a una corruzione della contabilità della banda, poiché enqueue_task_dl() non riconoscerà il lock holder come boostato.
Lo scenario si verifica quando: 1. Un task DEADLINE (donor) va in blocco su un mutex PI detenuto da un altro task DEADLINE (holder), ma l'holder non eredita i parametri (ad esempio, perché ha già una deadline più breve) 2. sched_setscheduler() cambia l'holder da DEADLINE a una classe inferiore mentre detiene ancora il mutex 3. L'holder dovrebbe ora ereditare i parametri DEADLINE dal donor ed essere accodato con ENQUEUE_REPLENISH, ma ciò non avviene
La correzione del problema introduce __setscheduler_dl_pi(), che rileva quando un task DEADLINE (proprio o boostato) viene schedulato verso una classe di priorità inferiore. In tal caso, la funzione fa sì che il task erediti i parametri DEADLINE del donor (pi_se) e imposta il flag ENQUEUE_REPLENISH per garantire una corretta contabilità della banda durante la successiva operazione di enqueue.
If you want to get best quality of vulnerability data, you may have to visit VulDB.