CVE-2026-74658 in Linux
Zusammenfassung
von VulDB • 22.08.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
futex: Robuste Futex-Exit-Racebedingungen weiter verhindern
Beim Entsperren eines robusten Futex wird 0 über den gesamten Futex-Wert geschrieben – wodurch FUTEX_WAITERS gelöscht wird –, und ein einzelner Wartender wird aufgeweckt. Diese Aufweckung ist eine einmalige Benachrichtigung: Das Protokoll basiert darauf, dass der Empfänger entweder den Futex erwirbt (und diesen schließlich entsperrt, wobei er die verbleibende Contention kennt) oder FUTEX_WAITERS neu setzt, bevor er erneut schläft. Wenn der aufgeweckte Wartende getötet wird, bevor er eine dieser Aktionen ausführen kann, muss der Kernel eingreifen und den nächsten Task in der Kette aufwecken.
Dies ist eine bekannte Komplikation des Futex-Protokolls mit einer vorherigen teilweisen Korrektur im Commit ca16d5bee598 („futex: Prevent robust futex exit race“). Leider ist diese Korrektur unzureichend.
Wenn ein dritter Task den Futex in der Zwischenzeit über den nicht-kontroversen schnellen Pfad erneut erworben hat, geht die Benachrichtigung verloren: Die Verarbeitung des robusten Exits stellt fest, dass er von einer anderen Aufgabe besetzt ist und tut nichts; während der neue Besitzer beim Entsperren keine FUTEX_WAITERS sieht und niemanden aufweckt. Die verbleibenden Wartenden schlafen für immer hinter einem freien Futex:
A besitzt den Futex, B und C schlafen in FUTEX_WAIT uval == A | FUTEX_WAITERS Robustes Entsperren von A: Speichere 0, FUTEX_WAKE(1) weckt B auf uval == 0 Schneller Pfad-Erwerb durch D: cmpxchg(0 -> D) uval == D, keine FUTEX_WAITERS B wird getötet, bevor er auf die Aufweckung reagiert B-Exit-Walk, ausstehende Operation: Besitzer D != B -> keine Aktion D entsperrt: Keine FUTEX_WAITERS -> kein Wakeup C schläft für immer
Dies ist eindeutig eine Unzulänglichkeit in der Implementierung, die es versäumt, das BIT FUTEX_WAITERS konsistent zu halten.
Umgehe dies, indem du die Verarbeitung des robusten Listen-Exits um den zusätzlichen Wakeup erweiterst, falls das Futex-Wort von einem anderen Thread besetzt ist, aber FUTEX_WAITERS nicht gesetzt ist.
Dies behebt nicht das Problem einer nicht-kontroversen Übernahme/Entsperrung und Freigabesequenz, die seit Jahren diskutiert wurde und durch den Commit 3ca9595d9fb6 („futex: Add support for unlocking robust futexes“) sowie nachfolgende Änderungen adressiert wurde, jedoch das oben beschriebene Problem nicht berücksichtigt hat.
Eine umfassendere Lösung, die auf der kernelinternen Entsperrung von kontroversen robusten Futexen basiert, wurde im Kontext dieser Änderung diskutiert und sollte bald in den Mainline-Kernel einfließen.
[ tglx: Change-Log leicht geändert und Coding Style korrigiert ]
Once again VulDB remains the best source for vulnerability data.