GhostLock: Linux-Schwachstelle aus 2011 ermöglichte Root-Zugriff ohne Privilegien

Eine Sicherheitslücke im Linux-Kernel, die seit über 15 Jahren in allen großen Distributionen vorhanden war, ermöglichte unprivilegierten Angreifern die vollständige Systemübernahme. Die als GhostLock (CVE-2026-43499) bezeichnete Schwachstelle wurde erst im April 2026 mit Kernel-Version 7.1 geschlossen. Entdeckt wurde sie von dem KI-gestützten Analysewerkzeug VEGA, das Google eine Belohnung von 92.337 US-Dollar im kernelCTF-Programm einbrachte.

Stack-Use-After-Free ohne besondere Voraussetzungen

GhostLock ist ein Use-After-Free-Bug auf dem Kernel-Stack. Für die Auslösung sind keine spezielle Kernel-Konfiguration oder erweiterte Rechte nötig. Ein unprivilegierter lokaler Angreifer kann ihn über gewöhnliche Thread-Systemaufrufe auslösen. Dabei erhält er einen hängenden Zeiger auf den Kernel-Stack, passt diesen nahezu beliebig an und manipuliert schließlich eine Funktionstabelle, um die Kontrolle über den Ausführungsfluss zu übernehmen. Die Folge: Privilegien-Eskalation bis zu Root-Rechten und Container-Escape, ohne dass zusätzliche Einstellungen wie User-Namespaces erforderlich sind.

Der rtmutex-Rework als Ursprung

Die Schwachstelle wurde mit dem Commit 8161239a8bcc („rtmutex: Simplify PI algorithm and make highest prio task get lock“) in Linux 2.6.39 eingeführt und blieb bis zur Behebung in Commit 3bfdc63936dd („rtmutex: Use waiter::task instead of current in remove_waiter()“) im April 2026 unentdeckt. Betroffen sind alle Kernel-Versionen von 2.6.39-rc1 bis 7.1-rc1, sofern CONFIG_FUTEX_PI=y gesetzt ist – eine Standardeinstellung in praktisch jeder Distribution.

Der Fehler liegt in der Hilfsfunktion remove_waiter() in kernel/locking/rtmutex.c. Sie wurde ursprünglich für den einfachen Fall geschrieben, dass ein Thread selbst auf eine Sperre wartet und anschließend aufräumt. Dabei verlässt sie sich auf die Annahme, dass current – der gerade laufende Thread – derjenige ist, dessen pi_blocked_on-Zeiger gelöscht werden muss.

Fehler im Proxy-Pfad

Diese Annahme bricht jedoch im Requeue-PI-Pfad. Über rt_mutex_start_proxy_lock() wird ein rtmutex_waiter stellvertretend für einen anderen, schlafenden Task in die Warteschlange eingereiht. current ist dann nicht der eigentliche Wartende, sondern der Thread, der den FUTEX_CMP_REQUEUE_PI-Aufruf ausführt. Kommt es zu einem Deadlock und die Operation wird mit -EDEADLK zurückgerollt, ruft der Proxy-Pfad remove_waiter() auf – und löscht damit pi_blocked_on des falschen Tasks. Der tatsächliche Wartende behält einen Zeiger auf seinen eigenen Stack-Frame, der freigegeben wird, sobald er in den Userspace zurückkehrt. Jede spätere PI-Kettenverfolgung folgt diesem hängenden Zeiger.

Container-Escape und Privilegien-Eskalation

Der so gewonnene dangling pointer lässt sich für eine stabile Exploitation nutzen. Der Angreifer kann einen Zeiger nahezu beliebig im Kernel-Speicher platzieren und eine Funktionstabelle kapern, um die Kontrolle über den Ausführungsfluss zu erlangen. In der von VEGA demonstrierten Umsetzung gelang dies mit einer Stabilität von 97 Prozent – ausreichend, um zuverlässig Root-Rechte zu erlangen und aus Containern auszubrechen.

Google zahlt 92.337 Dollar für den Exploit

Für die Ausarbeitung und Einreichung des Exploits im kernelCTF-Programm zahlte Google 92.337 US-Dollar an die Entdecker. Die Lücke war über eineinhalb Jahrzehnte in jedem Linux-System vorhanden, ohne entdeckt zu werden.

15 Jahre unentdeckt – KI spürt den Fehler auf

Dass GhostLock so lange übersehen wurde, liegt auch an der subtilen Natur des Fehlers: Lockdep, das Verifikationswerkzeug des Kernels, prüft lediglich, ob ein pi_lock gehalten wird, nicht aber, ob es der richtige ist. Erst das KI-gestützte Analysewerkzeug VEGA brachte die Schwachstelle ans Licht. Der Fix ersetzt den Zugriff auf current durch den korrekten Task des Waiters (waiter->task) und stellt sicher, dass pi_blocked_on beim richtigen Thread gelöscht wird. Betreiber sollten auf die neueste LTS-Version aktualisieren, die den Patch enthält.