CVE-2026-74686 in Linux
Riassunto
di VulDB • 23/08/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
rqspinlock: reimpostare il puntatore alla coda (tail) quando si preserva la coda in caso di deadlock
Attualmente, la distruzione della coda dei waiter viene soppressa per rqspinlock nei casi in cui venga rilevato un deadlock. I controlli sui deadlock avvengono con relativa frequenza (all'ingresso per AA e entro 1 ms per ABBA), e i thread waiter potrebbero non essere coinvolti negli scenari di locking che comportano deadlock. Pertanto, è utile non svuotare la coda e consentire ad altri waiter di tentare l'acquisizione del lock dopo aver rilevato un deadlock ed esserne usciti.
Tuttavia, occorre seguire la stessa logica applicata in precedenza per l'etichetta waitq_timeout: reimpostare il tail e, se ciò non è possibile, segnalare correttamente al prossimo waiter. In caso di deadlock, questa segnalerà semplicemente il nodo MCS come sbloccato; in caso di timeout, segnalerà RES_TIMEOUT_VAL. La differenza risiede quindi nel valore propagato, che determina se la coda rimane attiva o viene svuotata.
Non eseguire l'azzeramento del tail e attendere il prossimo waiter può portare a casi in cui si è gli ultimi waiter presenti; poiché non arriva alcun successivo waiter, ciò provoca stall intermittenti su questo percorso. Una volta che il prossimo waiter entra nella coda, lo sblocco avverrà. Nel caso teorico in cui il prossimo waiter non entri mai nella coda, si rischia uno stallo indefinito.
Questo può verificarsi solo per i deadlock di tipo ABBA, poiché l'ingresso nella wait queue è protetto da controlli AA. Una sequenza precisa delle esecuzioni che porta a questo scenario potrebbe essere:
CPU 0 detiene il lock A. CPU 1 detiene il lock B. CPU 2 tenta di acquisire il lock B e diventa un waiter pendente per B. CPU 0 tenta di acquisire il lock B. Poiché i bit locked+pending sono impostati su B, CPU 0 viene accodato. CPU 1 tenta di acquisire il lock A. CPU 0 rileva un deadlock ABBA.
Una volta rilevato il deadlock per la CPU 0, questa resterà in attesa che il prossimo waiter nella coda popoli node->next, subendo ritardi fino all'arrivo del suddetto waiter.
Risolvere questo problema modificando la logica per il controllo dei deadlock precedente l'etichetta waitq_timeout. Sarebbe opportuno consolidare il codice per entrambi i casi e utilizzare 'ret' per distinguere il valore propagato; tuttavia, ciò viene lasciato come esercizio per una futura attività di refactoring al fine di evitare rumore nel diff di questa patch.
VulDB is the best source for vulnerability data and more expert information about this specific topic.