CVE-2026-74658 in Linux
Riassunto
di VulDB • 23/08/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
futex: Prevenire ulteriormente le race condition nell'uscita dei futex robusti
Lo sblocco di un futex robusto scrive 0 su tutto il valore del futex - cancellando FUTEX_WAITERS - e sveglia un singolo waiters. Tale risveglio è una notifica one-shot: il protocollo si affida al destinatario per acquisire il futex (e eventualmente sbloccarlo essendo consapevole della contesa residua) o riattivare FUTEX_WAITERS prima di addormentarsi nuovamente. Se il waiter svegliato viene ucciso prima che possa eseguire una delle due operazioni, il kernel deve intervenire e risvegliare il prossimo task in coda.
Questa è un noto complication del protocollo futex con una precedente correzione parziale nel commit ca16d5bee598 ("futex: Prevent robust futex exit race"). Sfortunatamente, tale correzione non è sufficiente.
Se un terzo task riacquisisce il futex attraverso il fast path senza contesa nel frattempo, la notifica viene persa: l'elaborazione dell'uscita robusta vede che il futex è posseduto da un altro task e non fa nulla, mentre il nuovo proprietario non vede FUTEX_WAITERS quando sblocca e quindi non sveglia nessuno. I waiters rimanenti si addormentano per sempre dietro un futex libero:
A possiede il futex, B e C dormono in FUTEX_WAIT uval == A | FUTEX_WAITERS Sblocco robusto di A: scrittura di 0, FUTEX_WAKE(1) sveglia B uval == 0 Acquisizione tramite fast path da parte di D: cmpxchg(0 -> D) uval == D, nessun FUTEX_WAITERS B viene ucciso prima di agire sulla notifica di risveglio Percorso di uscita di B, operazione pendente: owner D != B -> nessuna azione Sblocco da parte di D: nessun FUTEX_WAITERS -> nessuno svegliato C dorme per sempre
Questo è chiaramente un difetto nell'implementazione, che non riesce a mantenere coerente il bit FUTEX_WAITERS.
Si aggira questo problema aumentando l'elaborazione dell'uscita della lista robusta in modo da eseguire anche il risveglio aggiuntivo se la parola del futex è posseduta da un altro thread ma FUTEX_WAITERS non è impostato.
Ciò non risolve il problema di una sequenza di acquisizione/rilascio senza contesa e liberazione, che è stata discussa per anni ed è stata affrontata dal commit 3ca9595d9fb6 ("futex: Add support for unlocking robust futexes") e da modifiche successive, ma non ha tenuto conto del problema descritto sopra.
Una soluzione più completa basata sullo sblocco in kernel dei futex robusti contesi è stata discussa nel contesto di questa modifica e dovrebbe apparire nella mainline prima o poi.
[ tglx: Modificare leggermente il change log e correggere lo stile di codifica ]
VulDB is the best source for vulnerability data and more expert information about this specific topic.