„Bad Epoll“ verstehen – ein „Use-After-Free“-Exploit, der Root-Rechte unter Linux und Android ermöglicht (CVE-2026-46242)

Die Kurzfassung

Zur Langfassung springen ↓

Was: „Bad Epoll“, erfasst unter der Kennung CVE-2026-46242, ist eine Race-Condition vom Typ „Use-after-free“ im epoll-Subsystem des Linux-Kernels. Im ep_remove()-Aufräumpfad löscht ein „close“-Pfad den epoll-Link der Datei und nutzt diesen weiterhin, während ein gleichzeitig ablaufender Dateifreigabevorgang – der diesen gelöschten Link erkennt – das zugrunde liegende Objekt freigibt. Ein nicht privilegierter Benutzer nutzt diesen versehentlichen Schreibvorgang aus, um Root-Rechte zu erlangen.

Auswirkung: Ein nicht privilegierter lokaler Benutzer gewinnt das Rennen, wandelt den 8-Byte-„Use-after-free“-Schreibvorgang über einen Cross-Cache-Angriff in die Kontrolle über eine „struct file“ um und eskaliert anschließend zu beliebigen Kernel-Lesezugriffen und einer Übernahme der Kontrollflusssteuerung – volle Root-Rechte. Der öffentliche PoC (J-jaeyoung/bad-epoll, eingereicht bei Google kernelCTF) weist eine Zuverlässigkeit von 99 % auf einem 6.12-Kernel auf, der auch die Basis für AlmaLinux 10 bildet.

Status: Der Fehler ist echt und wurde bereits im Upstream behoben. Er wurde im Februar privat gemeldet, am 24. April behoben und am 30. Mai öffentlich bekannt gegeben – die Behebung erfolgte fünf Wochen vor der Bekanntgabe, und es gab keine Ausnutzung in freier Wildbahn. Ursprünglich handelte es sich um einen „KernelCTF“-0-Day, doch für Verteidiger ist er heute ein N-Day mit einem öffentlichen Exploit.

Schweregrad: kernel.org und NVD stufen den Schwachpunkt mit einem CVSS-Wert von 7,8 als „Hoch“ ein (AV:L/AC:L/PR:L); Red Hat bewertet ihn mit 7,0 und stuft das ~6-Befehls-Race als schwer zu gewinnen ein. In beiden Fällen führt der Angriff zu Root-Rechten, und die Zuverlässigkeit des PoC von ~99 % macht dieses enge Zeitfenster zu einem praktischen und nicht zu einem theoretischen Problem.

Warum das wichtig ist: Bei den betroffenen Systemen handelt es sich um solche, bei denen lokale Isolation das Ergebnis ist: Shared Hosting, Multi-Tenant-Hosts, CI-Runner und Container-Knoten, auf denen nicht vertrauenswürdiger Code ausgeführt wird. epoll bildet die Grundlage für nahezu jeden Dienst, sodass es keine Angriffsfläche gibt, die deaktiviert werden könnte. Ein lokaler LPE ist hier das Ereignis, das die Sicherheitsgrenzen überschreitet.

Maßnahmen: Es gibt keine saubere Konfigurationsabhilfe – epoll lässt sich nicht deaktivieren. Isolieren Sie nicht vertrauenswürdige lokale Ausführungen und vergewissern Sie sich, dass der Kernel tatsächlich den Fix enthält, anstatt sich auf einen fehlgeschlagenen Exploit-Versuch zu verlassen. Ein rebootloser Patch von KernelCare wird derzeit analysiert; in den Repositories ist noch nichts verfügbar. Details siehe unten.

Es gibt zwei Gründe, die Sie dazu verleiten könnten, dieses Ticket vorzeitig zu schließen, und beide sind falsch.

Erstens gibt es die README-Datei des PoC selbst, in der es heißt, der Fehler betreffe nur Kernel „auf Basis von v6.4 oder neuer“, während Kernel auf Basis von v6.1 als sicher bezeichnet werden. Liest man das auf einem CloudLinux-9-Rechner – der auf 5.14 basiert –, würde man sich vernünftigerweise aus dem Geltungsbereich herausnehmen. Das wäre jedoch falsch. Der zweite Punkt ist ein sauberer Exploit-Lauf. Wenn man den öffentlichen PoC auf einen Kernel in einer kleinen VM richtet und beobachtet, wie er das Rennen einige hunderttausend Mal verliert, ist es leicht, „nicht reproduzierbar, nicht betroffen“ zu schreiben und weiterzumachen. Auch das ist falsch – und bei diesem Fehler sogar gefährlich.

„Bad Epoll“ ist eine Race-Condition vom Typ „Use-after-free“ im Eventpoll-Subsystem des Kernels – der Mechanismus hinter den epoll-Systemaufrufen, auf den im Wesentlichen jeder Netzwerkdienst auf dem Rechner angewiesen ist. Die Race-Condition tritt im Bereinigungspfad von ep_remove() auf, und das Zeitfenster ist etwa sechs CPU-Befehle breit. Verpasst man es, passiert nichts. Gelingt es jedoch – wie es der öffentlich zugängliche Exploit auf einem 6.12-Kernel mit hoher Zuverlässigkeit tut –, ist ein nicht privilegierter Benutzer auf dem besten Weg, Root-Rechte zu erlangen.

EL10 gilt als ausnutzbar, und EL9 ist durch den zurückportierten Einführungs-Commit sehr wahrscheinlich ebenfalls betroffen; es handelt sich also nicht um eine vorsichtige Interpretation einer Herstellerwarnung. Es handelt sich um einen echten Fehler mit einem echten Upstream-Fix, und ein öffentlicher, als Angriffswerkzeug genutzter Exploit ist bereits in einer Einreichung bei kernelCTF zu finden.

So funktioniert „Bad Epoll“

epoll verwaltet ein struct eventpoll Objekt, gestützt durch ein struct file, und zwar für jede epoll-Instanz. Es ist wichtig, dies sauber zu beenden, da es vorkommen kann, dass zwei Pfade fast gleichzeitig dasselbe schließen: der epoll-Entfernungspfad und eine gleichzeitig stattfindende Freigabe der zugrunde liegenden Datei.

Der Fehler ist ein kleiner Reihenfolgefehler in diesem Teardown. Innerhalb von `ep_remove()` löschte der alte Code die epoll-Zuordnung der Datei (file->f_ep), während man file->f_lock, und verwendete dann weiterhin dieselbe Datei und deren Eventpoll-Daten innerhalb des kritischen Abschnitts. Ein gleichzeitiger __fput() Wird in diesem Zeitfenster der Fast-Path der Freigabe aufgerufen, wird der vorübergehende NULL-Wert erkannt f_ep, kommt zu dem Schluss, dass keine epoll-Bereinigung erforderlich ist, und fährt direkt fort mit f_op->release. In einer „epoll-watches-epoll“-Konfiguration gibt dieser Pfad den überwachten Eintrag frei struct eventpoll vollständig. Der erste Pfad läuft noch, und sein nächster hlist_del_rcu() schreibt über einen Zeiger, der in gerade freigegebenem Speicher eingebettet ist.

[Unprivileged local process]
│  creates linked epoll objects backed by struct file
▼
[Two close paths race inside ep_remove()]
│  path A clears file->f_ep, keeps using the file
│  path B (__fput) sees NULL f_ep, skips epoll cleanup
▼
[Path B frees the watched struct eventpoll / recycles the file slot]
│  path A's hlist_del_rcu() writes into freed memory
▼
[Attacker-controlled 8-byte use-after-free write]
▼
[Cross-cache reclaim gives control of a struct file]
▼
[Arbitrary kernel read + control-flow hijack]
▼
[uid=0 root shell]

Der Schreibvorgang selbst erfolgt acht Bytes tief in freigegebenem Speicher, was zunächst noch verkraftbar klingt, bis man nachverfolgt, was der Exploit damit anstellt. Die öffentliche Kette verwendet vier epoll-Objekte in zwei Paaren: Das Schließen eines Paares löst den Race-Condition-Angriff aus, das andere Paar wird zum Opfer. Dadurch wird der 8-Byte-Schreibvorgang zu einem „Use-after-free“-Angriff auf einen struct file, nutzt die „Cross-Cache-Heap-Reclamation“, um diesen Speicherplatz durch ein vom Angreifer kontrolliertes Objekt zu ersetzen, und erreicht so beliebige Lesezugriffe auf den Kernel sowie die Übernahme der Kontrollflusssteuerung.

Gerade wegen der geringen Ausprägung des Race-Condition-Problems lässt sich der Fehler leicht falsch einschätzen – und deshalb blieb er jahrelang unbemerkt. Mit demselben Commit aus dem Jahr 2023, durch den dieser Fehler eingeführt wurde, wurde auch ein verwandtes Race-Condition-Problem (CVE-2026-43074) eingeführt, das bereits früher im Jahr 2026 entdeckt und behoben wurde. Diese Korrektur hat „Bad Epoll“ jedoch nicht behoben. Dass in diesem Jahr eine Epoll-Korrektur vorgenommen wurde, ist kein Beweis dafür, dass beide Fehler behoben wurden.

Was sich durch den Upstream-Fix ändert

Der Fix ist klein und in sich geschlossen, weshalb er sich problemlos portieren lässt. Er verhindert, dass ep_remove() mit einer ungeschützten Referenz auf die Datei arbeitet, die entfernt werden soll.

Der korrigierte Pfad ordnet die Datei ganz vorne ein und nimmt dabei eine Referenz über epi_fget() und dabei ein struct file *file __free(fput) abfangen, bevor es berührt file->f_lock. Solange diese Referenz bestehen bleibt, kann die Referenzanzahl der Datei nicht auf null sinken, daher __fput() kann nicht gestartet werden, und der parallele Freigabepfad kann die Datei oder ihr eventpoll-Objekt nicht aus dem Bereinigungsprozess freigeben. Wenn die Sperre nicht aufgehoben werden kann, bricht ep_remove() ab, bevor es die Bereinigung durchführt f_ep, und der Freigabepfad folgt dem normalen, langsameren Bereinigungsprozess, der über den „eventpoll“-Mutex synchronisiert wird, anstatt in einen Wettlauf zu geraten.

Konzeptionell:

Before:  clear epoll link → keep using file → concurrent release frees it → write into freed memory
After:   pin file reference → do cleanup while pinned → concurrent release cannot free → release reference

Diese eine Änderung behebt beide Teile des Fehlers: die Freigabe des überwachten struct eventpoll, sowie das Recycling der struct file Slot, während der ursprüngliche Pfad weiterhin davon ausgeht, dass er eine gültige Sperre hält.

Wer ist betroffen?

Die kurze Antwort für die CloudLinux- und AlmaLinux-Familie: Die Versionen 9 und 10 sind betroffen und dies wurde bestätigt, bei Version 8 wird davon ausgegangen, dass sie nicht betroffen ist.

Betroffen:

• CloudLinux 10 / AlmaLinux 10 (basierend auf 6.12): Eine ausschließlich zum Absturz führende Variante des öffentlichen PoC lässt einen nicht privilegierten AlmaLinux 10-Host auf Bare-Metal-Hardware innerhalb von Sekunden zuverlässig abstürzen – ein ausnutzbarer, als Waffe einsetzbarer „Use-after-free“-Exploit, keine Labor-Kuriosität. Es handelt sich um dieselbe 6.12-Basis, auf der der vollständige Exploit im Upstream mit einer Zuverlässigkeit von 99 % Root-Rechte erlangt.
• CloudLinux 9 / AlmaLinux 9 (basierend auf 5.14): Wahrscheinlich betroffen durch den zurückportierten Einführungs-Commit – Red Hat führt RHEL 9 als betroffen auf, da der Einführungs-Commit in diese Zweiglinie zurückportiert wurde. Die Reproduzierbarkeit in der 5.14-Zweiglinie wird derzeit noch überprüft; betrachten Sie diese Version daher bis zur Bestätigung als betroffen, nicht jedoch als intern nachgewiesen.

Es wird davon ausgegangen, dass dies keine Auswirkungen hat; bitte überprüfen Sie dies, bevor Sie sich darauf verlassen:

• CloudLinux 8 / AlmaLinux 8 (basierend auf 4.18): Red Hat stuft RHEL 7 und 8 als nicht betroffen ein, und CL8 dürfte aufgrund dieser Einstufung ebenfalls nicht betroffen sein. Falls ein Prüfer oder Kunde eine eindeutige Bestätigung benötigt, sollten Sie die Quelle überprüfen, anstatt dies einfach zu behaupten.

Das Versionsfenster ist die erste Falle. Die PoC-README-Datei beschreibt einen Mainline-Bereich ab Version 6.4 und bezeichnet Kernel auf Basis von Version 6.1 als sicher. Das trifft zwar auf Mainline zu, ist für Enterprise Linux jedoch irrelevant, da Anbieter die eingeführte Änderung in viel ältere Versionszweige zurückportieren. Ein EL9-Kernel auf Basis von 5.14 liegt deutlich unter Version 6.4 und ist weiterhin betroffen. Leiten Sie keine Rückschlüsse von der Upstream-Version auf Ihren EL-Rechner ab.

Eine fehlgeschlagene Reproduktion ist die zweite Falle. Race-Exploits reagieren äußerst empfindlich auf die Anzahl der Kerne, die Scheduling-Verfahren, die Heap-Anordnung und die Build-Konfiguration. Ein früher Test auf einer kleinen VM mit zwei vCPUs führte zu keinem Race-Condition und schien einwandfrei zu sein; ein leistungsfähigerer Reproduzierer auf einem Multi-Core-Bare-Metal-System löste jedoch innerhalb von Sekunden an derselben Kernelzeile einen Panic aus. Der Fehler lag in der schlechten Testumgebung, nicht in einem gepatchten Kernel. Betrachten Sie eine nicht reproduzierte Race-Condition nicht als Zeichen für Sicherheit.

Überprüfen Sie daher anhand des Quellcodes und nicht anhand des Exploits. Die Suche nach dem Hash des Upstream-Commits mit „grep“ ist irreführend, da Backports den Hash entfernen. Überprüfen Sie stattdessen das Korrekturmuster innerhalb von `ep_remove()`:

grep -n 'epi_fget\|__free(fput)' /usr/src/kernels/$(uname -r)/fs/eventpoll.c

Wenn ep_remove() die Datei mit epi_fget() und ein __free(fput) Vorsicht vor dem Berühren file->f_lock, ist der Patch vorhanden. Fehlen diese, ist der Kernel nicht gepatcht, und jeder negative Exploit, der darauf ausgeführt wurde, war ein „False Negative“.

Jetzt Maßnahmen ergreifen

Um es ganz klar zu sagen: Es gibt keine saubere Konfigurationsmaßnahme zur Risikominderung.

epoll ist eine zentrale Syscall-Schnittstelle. nginx, php-fpm, mysqld, systemd – fast alles auf einem Produktionsserver läuft darauf, und es ist in jedem Allzweck-Kernel aktiviert. Es gibt keinen sysctl-Schalter, kein Modul, das auf die Blacklist gesetzt werden muss, und keine Capability, die entfernt werden könnte, um die Sicherheitslücke zu schließen, ohne dabei die Workloads zu beeinträchtigen, die den Server finanzieren. Es sind nicht einmal Benutzernamensräume oder spezielle Capabilities erforderlich; der Forscher stellt fest, dass der Zugriff auch aus eingeschränkten Kontexten möglich ist, einschließlich einer Browser-Renderer-Sandbox. Wer Ihnen hierfür einen einzeiligen „epoll-Hardening-Schalter“ anbietet, verkauft Ihnen eine defekte Lösung.

Da der Fehler nur lokal auftritt (AV:L, PR:L), sind die bewährten Maßnahmen genau die langweiligen, die Sie bereits kennen:

• Schränken Sie ein, wer auf den betroffenen Hosts Code ausführen darf, da dieser Fehler einen lokalen, nicht privilegierten Zugangspunkt erfordert; je weniger Zugangspunkte, desto geringer das Risiko.
• Isolieren Sie nicht vertrauenswürdige und teilweise vertrauenswürdige lokale Ausführungsprozesse – Kundencode, CI-Jobs, Build-Schritte – von den Hosts, die Sie am dringendsten schützen müssen, oder verlagern Sie sie auf Kernel, die Sie zuerst reparieren können.
• Priorisieren Sie diejenigen Hosts, bei denen die lokale Isolation die eigentliche Sicherheitsgrenze darstellt: Shared Hosting, Multi-Tenant-Knoten, CI-Runner, Container-Hosts.
• Vergewissern Sie sich anhand der oben beschriebenen Quellcodeprüfung, dass der Kernel die Korrektur enthält, anstatt die Sicherheit allein aus der Tatsache abzuleiten, dass der Exploit ohne Fehler abläuft.

Entscheidungsmoment. Wenn auf einem Host kein nicht vertrauenswürdiger lokaler Code ausgeführt wird und er nur eine kleine Gruppe vertrauenswürdiger Benutzer hat, ist das Restrisiko geringer, und Sie können Patches in Ihrem normalen Rhythmus installieren, sobald Errata oder ein Patch ohne Neustart verfügbar sind. Wenn auf einem Host Code ausgeführt wird, den Sie nicht kontrollieren – Shared Hosting, CI, Multi-Tenant –, behandeln Sie ihn ab sofort als gefährdet und rücken Sie einen Patch ohne Neustart oder einen korrigierten Kernel an die Spitze der Warteschlange, sobald einer verfügbar ist.

Rebootloses Patchen

Genau für diese Art von Fehlern gibt es Patches, die ohne Neustart installiert werden können. Die Änderung aus dem Upstream ist zwar verfügbar, schützt ein laufendes System jedoch nicht: Der Hersteller muss sie zurückportieren, Sie müssen das Paket installieren, und der Rechner muss mit dem neuen Kernel hochfahren. Bei diesem letzten Schritt besteht weiterhin ein Sicherheitsrisiko, und genau dort, wo es am wichtigsten ist, ist es am schwierigsten.

Der Fix ist eine kleine, in sich geschlossene Korrektur zur Bereinigung, was ihn zu einem guten Kandidaten für einen Patch ohne Neustart macht. Es handelt sich um einen direkten Backport des ep_remove()-Referenz-Pins aus dem Upstream, der auf den laufenden Kernel angewendet wird, sodass die Bereinigung während der Ausführung die darunterliegende Datei nicht mehr freigeben kann – dieselbe Garantie wie beim Upstream-Fix, jedoch ohne Neustart.

Für CloudLinux und AlmaLinux ist die Lösung bereits identifiziert – sie lässt sich als direkter Backport des ep_remove()-Referenz-Pins aus dem Upstream portieren (RHEL 10-Backport, Gerrit 257974). Der KernelCare-Backport wird derzeit noch analysiert, wobei die Reproduzierbarkeit unter EL10 und EL9 überprüft wird. Daher hat noch kein Patch die Validierung abgeschlossen und es befindet sich noch keiner in den Feeds „testing“, „main“ oder „ePortal“. LibCare fällt hier nicht in den Geltungsbereich – es handelt sich um einen reinen Kernel-Fehler, sodass es keinen Aspekt im Userspace-Bibliotheksbereich gibt, der gepatcht werden müsste.

Sobald ein Release verfügbar ist, sieht die Bereitstellung über den Testkanal (Feed) wie folgt aus:

kcarectl --update --prefix test

So überprüfen Sie, ob das aktuelle Patch-Build-Datum auf oder nach dem Veröffentlichungsdatum liegt:

kcarectl --info | grep kpatch-build-time

Ein Build-Datum allein sagt noch nichts aus. Überprüfen Sie direkt die CVE-Zuordnung, das Erratum des Herstellers, das Quellmuster oder den Status des KernelCare-Patches.

KernelCare herunterladen →

Erkennung

„Bad Epoll“ hinterlässt keine eindeutige Signatur auf der Festplatte. Der Exploit läuft vollständig im Kernel-Speicher ab – er gewinnt ein Race-Condition-Rennen, korrumpiert ein freigegebenes Objekt und schreibt den Kontrollfluss um –, sodass Tools zur Dateiintegritätsprüfung nichts erkennen können. Der Auslöser besteht aus gewöhnlichen Schnittstellen (Erstellen von epoll-Instanzen, Registrieren von Deskriptoren und Timer-File-Deskriptoren sowie deren Schließen), die auf jedem Linux-Host normal sind. Dadurch wird die Erkennung auf das Verhalten verlagert, und jeder der folgenden Punkte ist ein Hinweis, kein Beweis:

• Nicht privilegierte Prozesse, die in engen Schleifen eine große Anzahl von epoll-Instanzen und timerfds erstellen und wieder auflösen, was dem wiederholten Auslösen eines engen Race-Condition-Szenarios entspricht.
• Kernel-Oops oder Fehler durch Listenbeschädigung im Teardown-Pfad von „eventpoll“, mit Signaturen rund um ep_show_fdinfo, ep_clear_and_put, ep_eventpoll_release, oder __fput.
• Wiederholte Kernel-Panics und Neustarts auf einem Multi-Core-Host, ohne dass Hardware- oder Konfigurationsänderungen vorliegen, die dies erklären könnten – ein reiner Crash-Trigger löst innerhalb von Sekunden einen Panic aus.
• Ein lokaler Benutzer oder ein Dienstkonto, das kurz nach einer der oben genannten Aktivitäten Berechtigungen erhält, ohne dass ein entsprechendes „sudo“- oder Anmeldeereignis vorliegt.

Falls auf einem exponierten EL9- oder EL10-Host nicht vertrauenswürdiger oder nur teilweise vertrauenswürdiger lokaler Code ausgeführt wurde und Sie im epoll-Teardown-Pfad gehäufte Kernel-Instabilitäten feststellen, sollten Sie der Installation von Patches Priorität einräumen und den Host als einen Fall betrachten, der einer genaueren Überprüfung bedarf – neue Konten oder SSH-Schlüssel, geänderte Authentifizierungskonfiguration, unerwartete Dienste –, anstatt saubere Datei-Hashes als Zeichen dafür zu werten, dass keine Kompromittierung vorliegt.

Warum gerade dieses Thema wichtig ist

„Bad Epoll“ ist keine Remote-Code-Ausführung. Niemand kann damit Ihren Server über das Internet kompromittieren. Für die Umgebungen, in denen das Problem tatsächlich auftritt, ist das ein schwacher Trost.

Beim Shared Hosting wird Kundencode ausgeführt. CI-Runner führen genau das aus, was ihnen der letzte Pull-Request vorgibt. Container und Kubernetes-Knoten führen Workloads auf unterschiedlichen Vertrauensstufen aus, und Multi-Tenant-Hosts dienen speziell dazu, die Mandanten voneinander zu trennen. In jedem dieser Fälle ist eine lokale Privilegienerweiterung das Ereignis, das das gesamte Design verhindern soll. Sie wandelt Code, dessen Ausführung erlaubt war, in Code um, der als Root ausgeführt wird, wo dies niemals hätte geschehen dürfen. Dass der Fehler zudem von Orten aus erreichbar ist, an denen die meisten Kernel-Fehler nicht auftreten, wie beispielsweise in der Sandbox eines Browser-Renderers, vergrößert die Angriffsfläche nur noch weiter.

Der Grund, warum man hier leicht einen Fehler machen kann, ist derselbe, warum es gefährlich ist. Drei plausible Anzeichen deuten alle auf „sicher“ hin und sind doch irreführend: Die Versionsangabe „v6.4+“ lässt Backports in das auf 5.14 basierende EL9 außer Acht, ein fehlgeschlagener Exploit-Versuch ignoriert, wie schwer es ist, einen Race-Condition-Angriff mit sechs Befehlen ohne großen Aufwand auszulösen, und die bereits Anfang des Jahres durchgeführte epoll-Korrektur hat keinerlei Auswirkungen auf dieses Problem. Vertraut man einem dieser Anzeichen, stuft man einen anfälligen Host fälschlicherweise als sicher ein.

Das Risiko konzentriert sich dort, wo es immer liegt: auf den Servern, die ein paar Updates im Rückstand sind, auf den langlebigen CI-Runner, die niemand neu startet, und auf den Multi-Tenant-Hosts, bei denen ein Wartungsfenster erst ausgehandelt werden muss. Genau das sind die Hosts, bei denen ein „N-Day“-Problem mit einem öffentlich zugänglichen PoC still und leise zu einem Problem wird, das noch am selben Tag behoben werden muss – und bei denen ein Patch ohne Neustart den Unterschied ausmacht zwischen einer Behebung noch heute und einer Behebung erst im nächsten Quartal.

Checkliste für priorisierte Sanierungsmaßnahmen

• Behandeln Sie CloudLinux 9 und CloudLinux 10 als betroffen und bestätigt. Schließen Sie CL9 nicht aufgrund des Hinweises „v6.4+“ aus – der entsprechende Commit wurde in die 5.14-Reihe zurückportiert.
• Überprüfen Sie jeden Kernel anhand des Quellcodes und nicht anhand des Ergebnisses des Exploits: Überprüfen Sie ep_remove() auf den epi_fget() + __free(fput) Muster korrigieren und einen fehlgeschlagenen PoC-Lauf als nicht aussagekräftig behandeln.
• Gehen Sie nicht davon aus, dass die Aussage „Wir haben dieses Jahr einen epoll-Fehler behoben“ auch diesen Fall abdeckt; der Fix für die verwandte CVE-2026-43074 behebt den „Bad Epoll“-Fehler nicht.
• Priorisieren Sie Hosts, bei denen die lokale Isolation die Sicherheitsgrenze darstellt: Shared Hosting, Multi-Tenant-Knoten, CI-Runner sowie Container- und Entwicklungshosts, auf denen nicht vertrauenswürdiger Code ausgeführt wird.
• Reduzieren und isolieren Sie nicht vertrauenswürdige lokale Ausführungen, bis eine Lösung vorliegt. Es gibt keine Abhilfemaßnahme über die Konfiguration – epoll lässt sich nicht deaktivieren.
• Überprüfen Sie CloudLinux 8 direkt an der Quelle, bevor Sie anderen mitteilen, dass alles in Ordnung ist.
• Suchen Sie nach ungeklärten Kernel-Panics und ungewöhnlichen epoll-/timerfd-Aktivitäten im teardown-Pfad von eventpoll, und betrachten Sie fehlerfreie Datei-Hashes als unzureichenden Beweis.
• Wenden Sie den „rebootless“-Patch von KernelCare an, sobald dieser validiert und in den Feed aufgenommen wurde, insbesondere auf den Hosts, bei denen ein Neustart am schwierigsten ist. Der Patch wird derzeit noch analysiert; K-Tags werden hier veröffentlicht, sobald die Releases verfügbar sind.

Patches für jeden Kernel – ganz ohne Neustart. Wenn Sie KernelCare noch nicht nutzen, ist jetzt der richtige Zeitpunkt, um zu erfahren, wie Patches ohne Neustart kritische Linux-Systeme schützen – ganz ohne Notfall-Wartungsfenster oder Ausfallzeiten.

Holen Sie sich KernelCare noch heute →

Referenzen

• Red Hat CVE-2026-46242 – https://access.redhat.com/security/cve/cve-2026-46242
• NVD CVE-2026-46242 (kernel.org CNA, CVSS 3.1 7,8) – https://nvd.nist.gov/vuln/detail/CVE-2026-46242
• linux-cve-announce – https://lore.kernel.org/linux-cve-announce/
• Öffentlicher PoC und Analyse der Grundursache (Jaeyoung Chung, Google kernelCTF) – https://github.com/J-jaeyoung/bad-epoll
• Vorheriger Korrektur-Commit a6dc643c6931 (24.04.2026); den Fehler verursachender Commit 58c9b016e128 (08.04.2023, Mainline v6.4)
• Verwandter Fehler CVE-2026-43074 (derselbe Commit, der den Fehler verursacht hat; separat behoben)