j-jaeyoung/bad-epollLinux-Kernel-Exploit zur Privilegieneskalation für CVE-2026-46242, ein Race-Condition-Use-after-Free in epoll, mit 99 % zuverlässigem Root-Zugriff auf Desktops, Servern und Android-Geräten.
Ein Prozess ohne Privilegien erlangt auf Google kernelCTF Root-Rechte.
Bad Epoll (CVE-2026-46242) ist ein Use-after-Free durch eine Race Condition im epoll-Subsystem des Linux-Kernels. Dieser Fehler erlaubt es einem Prozess ohne Privilegien, Root-Rechte zu erlangen, nicht nur auf Linux-Desktops und -Servern, sondern auch auf Android-Geräten.
Bad Epoll wurde von Jaeyoung Chung als 0-Day-Einreichung bei Google kernelCTF gemeldet und ausgenutzt. kernelCTF belohnt einen Linux-Kernel-Exploit mit 71.337 $ oder mehr.
[!NOTE] Die KI von Anthropic, Mythos, fand einen weiteren Race-Bug im selben epoll-Code, übersah jedoch Bad Epoll.
Ein seltener Fehler, der Android rooten kann. Die meisten Linux-Privilege-Escalation-Fehler können Android überhaupt nicht rooten. Copy Fail und seine Varianten benötigen beispielsweise Module, die Android nie lädt. Von den etwa 130 Schwachstellen, die auf Googles kernelCTF ausgenutzt wurden, kommen nur etwa zehn als Kandidaten zum Rooten von Android in Frage. Bad Epoll ist eine davon.
Kein Kill-Switch. Copy Fail und seine Varianten können neutralisiert werden, indem ihre verwundbaren Module entladen werden, aber epoll bietet keine solche Option. Es ist eine Kernfunktion des Kernels, auf die sich Betriebssystem, Netzwerkdienste und Browser gleichermaßen verlassen. Der einzige Weg, das Problem zu beheben, ist das Einspielen des Patches.
Winziges Race-Fenster, aber der Angriff ist zu 99 % zuverlässig. Das Race-Fenster des Fehlers ist nur etwa sechs Befehle breit, und ein normaler Versuch trifft es fast nie. Der Exploit verbreitert dieses Fenster und führt eine Wiederholungsschleife aus, die den Kernel nie zum Absturz bringt. Das Ergebnis ist ein zu 99 % zuverlässiger Exploit, wie die Angriffsübersicht unten beschreibt.
Ein einzelner Commit aus dem Jahr 2023 führte zwei separate Race Conditions in den epoll-Code ein, der insgesamt nur etwa 2.500 Zeilen umfasst. Beide entpuppten sich als kritische Fehler, die zu Privilege Escalation führen können.
Der erste wurde von Anthropics Mythos gefunden und als CVE-2026-43074 gemeldet. Dieses Ergebnis ist für sich genommen beeindruckend, da Race-Bugs im Kernel bekanntermaßen schwer zu finden sind. Es zeigte die Fähigkeit eines Frontier-KI-Modells, Race-Bugs zu finden. Ein unabhängiger Forscher reichte später einen 1-Day-Exploit dafür bei kernelCTF ein.
Die andere Race Condition ist Bad Epoll, die Mythos übersehen hat. Da Mythos den ersten Fehler in diesem kleinen epoll-Codepfad gefunden hat, hat es denselben Bereich wahrscheinlich mit beachtlicher Tiefe untersucht. Wir können nicht genau wissen, warum es Bad Epoll übersehen hat, aber zwei Faktoren haben das Auffinden wahrscheinlich erschwert.
Das Race-Fenster ist winzig. Es ist nur etwa sechs Befehle breit, sodass die genaue Thread-Verschränkung schwer vorstellbar ist, selbst wenn man den verwundbaren Code betrachtet.
Es gab wenige Laufzeit-Hinweise. Nachdem CVE-2026-43074 behoben wurde, löst der Use-after-Free von Bad Epoll normalerweise kein KASAN aus, den wichtigsten Speicherfehler-Erkenner des Kernels. Ohne dieses Signal hatte Mythos möglicherweise nicht genug Vertrauen, um es als echten Fehler zu melden.
Auch die Behebung von Bad Epoll war schwierig. Der erste Patch der Maintainer behob das Problem nicht vollständig, und ein korrekter Patch landete erst zwei Monate nach der ersten Meldung des Fehlers. Das ist eine lange Zeit für einen Kernel, der Sicherheitsprobleme normalerweise mit Dringlichkeit behandelt.
Insgesamt zeigt Bad Epoll, wie schwierig Race Conditions in jeder Phase sind. Sie sind selbst für ein Frontier-Modell schwer zu finden, schwer korrekt zu beheben und, wie der nächste Abschnitt zeigt, schwer zuverlässig auszunutzen. Es deutet auch auf eine Richtung der Schwachstellenforschung hin, die es selbst in Gegenwart von Frontier-KI-Modellen noch zu erkunden lohnt: die Aufdeckung realer Sicherheitsauswirkungen hinter engen Timing-Bedingungen und schwachen Hinweisen.
Hier ist ein Überblick auf hoher Ebene über den Angriff, für die Neugierigen.
Zwei verknüpfte epoll-Objekte. Das gleichzeitige Schließen beider löst die Race Condition aus.
Zwei Schließpfade von epoll laufen gleichzeitig ab und kollidieren. Einer gibt ein Objekt frei, während der andere noch hineinschreibt, und das ist der Use-after-Free (UAF).
Das Race-Fenster und wie der Exploit es antreibt.
Der Exploit verwendet vier epoll-Objekte, die in zwei Paaren gruppiert sind. Ein Paar löst die Race Condition aus, während das andere zum Opfer wird. Von dort verwandelt der Exploit den 8-Byte-UAF-Schreibzugriff in einen UAF auf ein Dateiobjekt und nutzt einen Cross-Cache-Angriff, um den Inhalt der Datei vollständig zu kontrollieren.
Den Fehler in einen beliebigen Kernel-Speicher-Read über /proc/self/fdinfo verwandeln.
Mit dieser Kontrolle erlangt der Exploit einen beliebigen Kernel-Speicher-Read über /proc/self/fdinfo. Schließlich übernimmt er den Kontrollfluss und führt eine ROP-Kette aus, um eine Root-Shell zu erhalten.
Weitere Details sind im vollständigen Exploit-Writeup und Code verfügbar.
Da epoll nicht deaktiviert werden kann, gibt es für Bad Epoll keinen einfachen Workaround. Das einzige Mittel ist das Einspielen des Patches.
