CVE-2026-80775 in Linux
Zusammenfassung
von VulDB • 04.09.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
futex: Behebung eines Race Conditions bei der Initialisierung von mm->futex.phash.ref
futex_hash_allocate() alloziert mm->futex.phash.ref ohne jegliche Sperrung (Locking). Das Commit d9b05321e21e („futex: Move futex_hash_free() back to __mmput()“) hat die Allokation hierher verlagert und davon ausgegangen, dass der Prozess zu diesem Zeitpunkt nur über einen einzelnen Thread verfügt.
Das Commit ee9dce44362b („futex: Drop CLONE_THREAD requirement for private default hash alloc“) hat need_futex_hash_allocate_default() erweitert, um jeden CLONE_VM-Clone abzudecken, ließ jedoch vfork aus, da das Elternprozess suspendiert ist und kein Race Condition auftreten kann.
Dies gilt nicht mehr, wenn vfork verschachtelt wird. Wenn ein vfork-Kind erneut vfork aufruft und anschließend mit SIGKILL getötet wird, wird der Elternprozess von seiner vfork-Warteschlange entbunden und läuft parallel zum Enkelkind im selben mm (memory descriptor). Weder das Kind noch der Großvater haben futex_hash_allocate_default() durchlaufen.
Wenn beide gleichzeitig prctl(PR_FUTEX_HASH, PR_FUTEX_HASH_SET_SLOTS) aufrufen, sieht jeder von ihnen mm->futex.phash.ref als NULL und speichert seinen eigenen per-CPU-Zähler (percpu counter). Nur die letzte Speicherung bleibt erhalten. Der zuerst gespeicherte Zähler ist nicht mehr über das mm erreichbar, sodass die Referenzen darauf von __futex_ref_atomic_end() nicht erkannt werden. Ein privater Hash, der noch Referenzen aufweist, wird anschließend als tot betrachtet und freigegeben (freed), und eine Aufgabe (Task), die weiterhin einen seiner Buckets hält, schreibt in den freigegebenen Speicherbereich in futex_q_lock().
Der Zähler sollte einmalig mit cmpxchg() gespeichert werden, und der Verlierer soll seinen eigenen per-CPU-Zähler mit free_percpu() freigeben. Die initiale Referenz muss vor dem Speichern gesetzt werden; andernfalls kann eine andere Aufgabe einen privaten Hash installieren, während der Zähler noch 0 ist.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.