Bad Epoll 0-Day: Linux- und Android-Kernel-Root-Exploit über Race Condition

Jeder Plattformverantwortliche, der eine Linux-Serverflotte betreibt oder eine Android-App mit WebView ausliefert, sollte die Offenlegung dieser Woche als Budgetgespräch behandeln – nicht als gewöhnliches Patch-Ticket. Ein neu veröffentlichter Kernel-Bug namens Bad Epoll verschafft einem unprivilegierten lokalen Benutzer einen zuverlässigen Weg zu Root-Rechten auf Servern, Desktops und Android-Geräten – und er ist von innerhalb des Chrome-Renderer-Sandboxes erreichbar. Diese Kombination verändert das Bedrohungsmodell für jeden, dessen Produktoberfläche einen Browser oder einen Android-Endpunkt berührt.

Die technische Geschichte ist interessant. Die geschäftliche Geschichte – wer die Kosten der Reaktion trägt – ist die, über die es sich diesen Monat intern zu streiten lohnt.

Wichtige Details

Die Schwachstelle, verfolgt als CVE-2026-46242, ist ein Use-after-free in ep_remove(), dem Abbau-Pfad innerhalb des epoll-Subsystems des Linux-Kernels. Wie CyberSecurityNews berichtete, löscht der Fehler file->f_ep unter file->f_lock, verwendet das File-Objekt aber weiterhin innerhalb des kritischen Abschnitts während hlist_del_rcu() und spin_unlock(). Ein gleichzeitiger __fput()-Aufruf kann ein transientes NULL beobachten, eventpoll_release_file() überspringen und direkt zu f_op->release übergehen – wodurch eine struct eventpoll freigegeben wird, die noch in Verwendung ist.

Da struct file vom Typ SLAB_TYPESAFE_BY_RCU ist, kann der freigegebene Slot durch alloc_empty_file() wiederverwendet werden. Das gibt einem Angreifer die Möglichkeit, kmem_cache_free() gegen den falschen Slab-Cache auszulösen. Forscher Jaeyoung Chung meldete den Bug als Zero-Day an Googles kernelCTF-Programm, das 71.337 US-Dollar oder mehr für funktionsfähige Linux-Kernel-Exploits zahlt.

Der Exploit selbst ist ein Meisterwerk handwerklicher Präzision. Er verwendet vier epoll-Objekte, die in zwei Paaren angeordnet sind; das Schließen eines Paares löst die Race Condition aus, während das andere zum Opfer wird. Dadurch wird ein 8-Byte-UAF-Schreibvorgang über einen Cross-Cache-Angriff in ein UAF auf einem File-Objekt umgewandelt. Von dort erhält der Angreifer einen beliebigen Kernel-Speicher-Lesezugriff über /proc/self/fdinfo und kapert den Kontrollfluss mit einer ROP-Kette, um eine Root-Shell zu erhalten. Das Race-Fenster ist etwa sechs Instruktionen breit. Chungs Exploit erweitert es, wiederholt Versuche sauber ohne Kernel-Panics und erreicht auf getesteten Zielen eine Zuverlässigkeit von rund 99 %.

Es gibt keine Umgehungslösung. Epoll ist eine zentrale Kernel-Komponente, die weder deaktiviert noch entladen werden kann – weshalb der Bug sowohl Android als auch Server kompromittiert. Administratoren müssen entweder den Upstream-Patch einspielen oder auf den Backport ihrer Distribution warten.

Warum das für Sicherheitsteams wichtig ist

Der entscheidende architektonische Fakt ist, dass Bad Epoll von innerhalb des Chrome-Renderer-Sandboxes erreichbar ist. In Kombination mit einem Renderer-Bug ergibt sich vollständige Kernel-Codeausführung von einer feindseligen Webseite aus. Für jedes Team, das ein Android-Produkt, eine Electron-Desktop-App oder eine Chromium-eingebettete Oberfläche ausliefert, ist das der Unterschied zwischen „Kernel-Bug, den wir patchen sollten" und „Remote-to-Root-Primitive, das wir modellieren müssen."

Die Konsequenzen für die Personalplanung sind unangenehm. Die meisten Sicherheitsorganisationen bei Series-B-Fintechs und mittelgroßen iGaming-Betreibern haben keinen kernel-kundigen Ingenieur im Team. Sie verfügen über AppSec-Generalisten und einen SOC-Vertrag. Wenn ein solcher Bug auftaucht, fällt die Frage, wer den Patch liest, den Backport validiert und den Rebuild für Mobile freigibt, an denjenigen, der sich meldet. Das ist eine Personallücke, keine Tooling-Lücke – und kein EDR-Anbieter wird sie für Sie schließen.

Die regulatorischen Risiken variieren je nach Branche, sind aber real. Lizenzierte iGaming-Betreiber, die spielerfacing Android-Apps in regulierten Märkten betreiben, haben Meldepflichtfristen bei Datenschutzverletzungen, die ab Entdeckung – nicht ab Ausnutzung – zu laufen beginnen. Fintechs mit SOC 2 oder ISO 27001 müssen die Reaktions-Timeline dokumentieren. Krypto-Custody-Unternehmen, die gehärtete Linux-Hosts betreiben, bekommen das Schlimmste aus beiden Welten: Kernel-Exposition auf der Serverseite und mobile Signing-Oberflächen auf der Clientseite.

Der CFO jedes verbraucherfacing Fintechs sollte seinen VP Engineering diese Woche fragen, welcher Prozentsatz der Android-Installationsbasis auf einem Kernel-Branch liegt, der tatsächlich einen zeitnahen Backport erhalten wird – und was es kostet, ein In-App-Update vor dem OEM-Zyklus zu erzwingen. Diese Zahl wird schlechter sein, als irgendjemand erwartet. Die Android-Kernel-Patch-Latenz war schon immer der hässliche Teil des mobilen Sicherheitsmodells, und genau dieser Bug ist der Typ, der auf Mittelklasse-Geräten sechs bis neun Monate lang ungepacht bleibt.

Auswirkungen auf die Branche

In der Offenlegung steckt eine zweite, stillere Geschichte, die meiner Meinung nach mehr dafür bedeutet, wie Sicherheitsbudgets in den nächsten zwölf Monaten verteilt werden. Ein einziger Kernel-Commit aus dem Jahr 2023 führte zwei separate Race Conditions in denselben 2.500-Zeilen langen epoll-Codepfad ein. Die erste, CVE-2026-43074, wurde von Anthropics Mythos-Modell gefunden. Mythos übersah Bad Epoll – die schwerer zu entdeckende zweite Race Condition – wahrscheinlich, weil das Timing-Fenster eng ist und der Bug selten KASAN auslöst, den primären Speicherfehler-Detektor des Kernels.

Lesen Sie das sorgfältig. KI-gestützte Kernel-Auditierung ist inzwischen gut genug, um echte Race Conditions in Produktions-Kernel-Code zu finden. Sie ist noch nicht gut genug, um jene zu finden, die keine Laufzeit-Hinweise hinterlassen. Das hat direkte Auswirkungen auf die Build-vs-Buy-Diskussion, die gerade in jeder Plattformorganisation stattfindet. Wenn Sie als CTO ein KI-Sicherheitsaudit-Produkt präsentiert bekommen, lautet die ehrliche Einordnung: Es wird die Klasse von Bugs finden, die bereits durch Instrumentierung sichtbar wird – und die Klasse verfehlen, die geduldige menschliche Intuition über Slab-Caches und RCU-Semantik erfordert. Preisen Sie entsprechend.

Für den Anbietermarkt ist Bad Epoll eine Erinnerung daran, dass kernelCTF-ähnliche Bug-Bounty-Programme unterbewertete Versicherungen sind. Google zahlte mindestens 71.337 US-Dollar für einen Bug, der in Kombination mit einem Renderer-Exploit auf dem offensiven Markt ein Vielfaches davon erzielen würde. Jedes Plattformunternehmen, dessen Produkt von der Integrität von Linux oder Android abhängt, sollte fragen, ob die eigenen Bounty-Obergrenzen am tatsächlichen Kostenrisiko der Alternative ausgerichtet sind. Bei den meisten ist das nicht der Fall.

Auch Distributionsanbieter kommen aus dieser Geschichte schlecht heraus. Der erste Patch-Versuch der Maintainer löste das Problem nicht vollständig, und ein korrekter Fix landete fast zwei Monate nach der ursprünglichen Offenlegung. Das ist das reale Fenster, das Ihr Incident-Response-Plan überleben muss – nicht das theoretische Zero-Day-Intervall.

Was zu beobachten ist

Drei Signale sind im nächsten Quartal es wert, verfolgt zu werden. Erstens: Wie schnell die großen Android-OEMs den Backport in ihren monatlichen Sicherheitsbulletins veröffentlichen. Historisch gesehen ist das eine breite Streuung – und dieser Bug wird zeigen, welche Anbieter tatsächlich in Kernel-Patch-Pipelines investiert haben und welche die Arbeit noch immer an Siliziumpartner weitergeben und auf das Beste hoffen.

Zweitens: Achten Sie auf die unvermeidliche Veröffentlichung eines öffentlichen Exploits. Chungs Writeup ist detailliert, die Race Condition ist gut charakterisiert, und 99 % Zuverlässigkeit bedeuten, dass jemand ihn vor Ende Q3 in ein Metasploit-Modul portieren wird. Das ist der Moment, in dem opportunistische Nutzung beginnt – und wenn dieser Bug in den CISA KEV-Katalog aufgenommen wird, mit einer harten föderalen Frist.

Drittens: Beobachten Sie, was Anthropic und seine Konkurrenten als Nächstes über KI-gestützte Kernel-Überprüfung veröffentlichen. Wenn die Reaktion auf Mythos' Versagen bei Bad Epoll ein Modell der zweiten Generation ist, das speziell auf Narrow-Window-Races und KASAN-unsichtbare Bugs abgestimmt ist, ändern sich die Wirtschaftlichkeit des Kernel-Auditings schnell. Wenn nicht, ist zu erwarten, dass der Markt für menschliche Kernel-Sicherheitsexperten brutal eng bleibt – und dass die Vergütung für diese Fähigkeit eine weitere Stufe steigt.

Teams, die ihren Sicherheitshaushalt für 2026 planen, sollten sich jetzt fragen, ob ihre mobile Update-Pipeline tatsächlich einen Kernel-Patch innerhalb des Zeitrahmens an Endnutzer ausliefern kann, den sie Regulierungsbehörden versprochen haben – und wenn nicht, was es wert ist, diese Lücke zu schließen, bevor das nächste Bad Epoll auftaucht.

Zusammenfassung

• Bad Epoll (CVE-2026-46242) ist ein Use-after-free im Linux-epoll-Abbau-Pfad, der einem unprivilegierten lokalen Benutzer mit rund 99 % Zuverlässigkeit Root-Rechte verschafft – ohne Umgehungslösung außer dem Upstream-Patch.
• Der Bug ist vom Chrome-Renderer-Sandbox aus erreichbar und verwandelt jeden Renderer-RCE in eine vollständige Kernel-Ausführungskette auf Linux und Android.
• Das Android-Risiko ist struktureller Natur: Epoll kann nicht deaktiviert werden, und die OEM-Patch-Latenz wird große Teile der Installationsbasis monatelang anfällig lassen.
• KI-gestützte Kernel-Auditierung fand den verwandten Bug (CVE-2026-43074), übersah aber Bad Epoll – ein nützlicher Datenpunkt für alle, die KI-Sicherheits-Tooling in ihren Budget 2026 einpreisen.
• Googles kernelCTF-Auszahlung von 71.337 US-Dollar ist ein Mindestbetrag, kein Maximum; interne Bounty-Programme mit niedrigeren Obergrenzen sind gegen genau diese Klasse von Bugs unterversichert.