Security 06.07.2026, 01:00 Aktualisiert: 06.07.2026, 01:00

Bad Epoll CVE-2026-46242: Linux prüfen, patchen und richtig einordnen

Bad Epoll betrifft Linux-Kernel mit epoll-UAF. Patchstände, Angriffspfad, Distributionen, Proxmox, Plesk, Container und Reboot-Prüfung.

Von Moritz Mantel · Veröffentlicht: 06.07.2026, 01:00 · Aktualisiert: 06.07.2026, 01:00

Stand: 06.07.2026, 01:00 Uhr CEST. Bad Epoll, CVE-2026-46242, ist eine lokale Rechteausweitung im Linux-Kernel. Der öffentliche Write-up zeigt einen sehr zuverlässigen Exploit auf Google-kernelCTF-Zielen, aber das ist keine unauthentifizierte Remote-Lücke. Entscheidend ist, ob dein laufender Kernel den Fix a6dc643c6931 oder einen Vendor-Backport enthält. Anders als bei Copy Fail, Dirty Frag, Fragnesia oder pedit COW gibt es hier keinen sinnvollen Modul-Killswitch. epoll ist Kernfunktionalität.

Kurzfassung

Worum es geht: Bad Epoll ist ein Race-Condition-Use-after-free im Linux-epoll-/eventpoll-Code (fs/eventpoll.c).
CVE: CVE-2026-46242.
Remote allein ausnutzbar: Nein. Ein Angreifer braucht lokale Code-Ausführung, zum Beispiel Shell-Zugriff, eine kompromittierte Webanwendung, einen CI-Job, Plugin-Code, Code in einem Container oder einen Browser-Renderer-Exploit.
Warum es trotzdem ernst ist: Der Forscher nennt 99 Prozent Erfolgsrate auf lts-6.12.67 und 98 Prozent auf einem Google-COS-kernelCTF-Ziel. Außerdem braucht der Trigger keine besonderen Linux-Capabilities und keine unprivileged user namespaces.
Kein einfacher Workaround: epoll lässt sich nicht wie algif_aead, esp4, esp6, rxrpc oder act_pedit blockieren, ohne normale Linux-Programme zu brechen.
Upstream-Fix: Mainline-Commit a6dc643c69311677c574a0f17a3f4d66a5f3744b, gelandet am 24.04.2026.
Betroffene Kernel: Grob alle Kernel mit der 2023 eingeführten epoll-Refcount-Änderung, vor allem Linien ab 6.4, sofern der Fix nicht zurückportiert wurde. NVD nennt zusätzlich einzelne stabile Backport-Bereiche wie 5.15.209 und 6.1.175.
Distributionen: Debian Trixie ist über Security gefixt, Debian Bullseye/Bookworm sind laut Tracker nicht betroffen. Ubuntu 24.04/25.10/26.04-Standardkernel stehen zum geprüften Stand noch auf verwundbar beziehungsweise in Arbeit. Red Hat listet RHEL 9 und 10 als betroffen, RHEL 7/8 als nicht betroffen. SUSE hat Tumbleweed-Pakete, viele SLE-15-SP6/SP7-, SLE-16-, Micro-6- und Leap-16/15.6-Stände aber noch als affected.
Saubere Lösung: Kernelupdate vom Vendor einspielen und danach wirklich in den gefixten Kernel booten oder einen passenden Livepatch nachweisen.
Nicht machen: Den öffentlichen Exploit nicht auf Produktivsystemen starten. Ein erfolgreicher Test ist Root-Ausführung im Kernel-Kontext, kein harmloser Vulnerability-Scan.

Was ist Bad Epoll?

epoll ist die Linux-Schnittstelle, mit der Programme viele File Descriptors effizient überwachen. Webserver, Datenbanken, Browser, Node.js, Python-Async-Frameworks, Container-Runtimes und zahllose Systemdienste nutzen das ständig. Genau deshalb ist Bad Epoll unangenehm: Der betroffene Code ist kein optionales Spezialmodul, sondern Alltags-Infrastruktur im Kernel.

Der Bug sitzt in der Aufräumlogik von eventpoll. Wenn ein epoll-File-Descriptor einen anderen epoll-File-Descriptor überwacht und beide Seiten fast gleichzeitig geschlossen werden, können zwei Kernel-Pfade auf dieselben Objekte schauen. Einer der Pfade räumt auf und gibt Speicher frei, während der andere Pfad noch mit Zeigern in diese Objekte arbeitet.

Das ist der Use-after-free. Aus Sicht des Kernels wird Speicher benutzt, der bereits freigegeben wurde und unter Umständen schon wieder für etwas anderes verwendet wird. Aus Sicht eines Angreifers ist das der Einstieg in Kernel-Speicherkorruption.

Bad Epoll wurde von Jaeyoung Chung als 0-Day-Submission an Googles kernelCTF gemeldet und später öffentlich beschrieben. Der Name passt zur “Bad”-Reihe von Android-rootbaren Kernelbugs, etwa Bad Binder, Bad IO_uring oder Bad Spin. Für Server ist aber nicht der Name relevant, sondern die Eigenschaft: Ein normaler lokaler Prozess kann unter passenden Bedingungen Root werden.

Wie funktioniert die Lücke technisch?

Die kurze Version: ep_remove() entfernt einen beobachteten File Descriptor aus einer epoll-Instanz. Dabei wurde file->f_ep unter file->f_lock auf NULL gesetzt, aber derselbe struct file wurde im kritischen Abschnitt danach weiter benutzt. Ein paralleler __fput()-Pfad konnte genau dieses kurze NULL sehen, den normalen eventpoll_release_file()-Cleanup überspringen und stattdessen direkt in den Release-Pfad laufen.

Beim Spezialfall “epoll überwacht epoll” ist das fatal. Der parallele Pfad kann das beobachtete struct eventpoll freigeben, während ep_remove() noch Listenzeiger benutzt, die in dieses freigegebene Objekt zeigen. Danach schreibt hlist_del_rcu() in bereits freigegebenen kmalloc-192-Speicher. Zusätzlich kann der Speicherplatz des alten struct file wegen SLAB_TYPESAFE_BY_RCU wiederverwendet werden, während der alte Pfad formal noch unter dem alten f_lock läuft.

Der Fix macht genau das, was in so einer Objektlebensdauer-Frage naheliegt: Er pinnt das struct file am Anfang von ep_remove() über epi_fget(). Solange diese Referenz gehalten wird, kann der parallele __fput()-Pfad das Objekt nicht bis auf Refcount null bringen. Damit bleiben auch die abhängigen eventpoll-Objekte über den kritischen Abschnitt hinweg am Leben.

Der öffentliche Exploit macht aus dieser Race-Situation mehr als nur einen Crash. Er nutzt mehrere epoll-Objekte, erweitert das kleine Zeitfenster, dreht in einer Retry-Schleife und wandelt den kleinen UAF-Write in stärkere Primitives um. Im Write-up wird daraus ein Kernel-Read über /proc/self/fdinfo und am Ende ein Control-Flow-Hijack per ROP-Kette. Das erklärt die hohe Erfolgsrate trotz winzigem Race-Fenster.

Das ist bewusst keine Exploit-Anleitung. Für Betrieb und Patchplanung reichen diese Punkte:

Es ist lokale Kernel-Speicherkorruption, kein normaler Dateischreibzugriff.
Der bekannte Trigger braucht keine besonderen Capabilities.
Unprivileged user namespaces zu deaktivieren entschärft andere Kernel-LPEs, entfernt Bad Epoll aber nicht.
Ein System kann gegen CVE-2026-43074 gepatcht sein und trotzdem CVE-2026-46242 brauchen.

Warum Bad Epoll anders ist als Dirty Frag und pedit COW

Die Linux-Kernel-Lücken der letzten Wochen sehen von außen ähnlich aus: lokaler Benutzer, Root möglich, öffentlicher PoC. Technisch sind sie aber verschieden.

Lücke	Bereich	Typischer Hebel	Temporäre Blockade möglich?
Copy Fail	`AF_ALG` / `algif_aead`	Page-Cache-Write über Crypto-/Splice-Pfad	Teilweise, etwa `algif_aead` oder AF_ALG blockieren
Dirty Frag	`xfrm`/ESP und `rxrpc`	Page-Cache-Write über Netzwerkfragmente	Teilweise, `esp4`, `esp6`, `rxrpc` blockieren
Fragnesia	XFRM/ESP-in-TCP	Page-Cache-Write über shared fragments	Teilweise, ESP-Pfade blockieren
pedit COW	`net/sched` / `act_pedit`	Page-Cache-Write nach fehlerhafter COW-Prüfung	Teilweise, `act_pedit` blockieren
Bad Epoll	`fs/eventpoll.c`	Use-after-free und Kernel-Speicherkorruption	Praktisch nein

Das macht Bad Epoll im Betrieb schwieriger. Bei Dirty Frag kann eine Blocklist ein akzeptabler Zwischenzustand sein, wenn IPsec und AFS nicht gebraucht werden. Bei pedit COW kann man act_pedit blockieren, wenn Traffic-Control-Features nicht gebraucht werden. Bei Bad Epoll gibt es diesen Weg nicht. epoll ist zu grundlegend.

Härtung hilft trotzdem, nur eben nicht als Entwarnung. KASLR, SLUB-Randomisierung, SELinux, AppArmor, seccomp, Container-Policies und reduzierte lokale Benutzerrechte können Ausnutzung erschweren oder den Schaden begrenzen. Sie ersetzen aber keinen Kernel-Fix.

Was braucht ein Angreifer?

Bad Epoll ist keine “ein Paket aus dem Internet und Root”-Lücke. Ein Angreifer braucht bereits eine Möglichkeit, Code auf dem Ziel auszuführen.

Typische Ausgangspunkte sind:

SSH-Zugang eines normalen Benutzers
kompromittierte WordPress-, TYPO3-, Shopware-, Laravel- oder Node.js-Anwendung
Plesk- oder Shared-Hosting-System mit mehreren Systembenutzern
GitLab Runner, GitHub Actions Runner, Jenkins-Agent oder anderer CI-Worker
Docker-, Kubernetes- oder LXC-Workload mit nicht vollständig vertrauenswürdigem Code
Plugin-Code, Build-Scripts, Cronjobs oder Deployment-Hooks
Browser-Renderer-Exploit auf Desktop oder Android
gestohlene Zugangsdaten eines unprivilegierten Benutzers

Auf einem Single-Tenant-Server ohne fremde Shells, ohne fremde Container und ohne unkontrollierten Build-Code ist das Risiko niedriger. Auf Shared-Hosting-, CI-, Kubernetes-, Proxmox-LXC- und Agenturservern ist es deutlich höher. Dort ist “lokal” keine enge Annahme. Eine Webshell oder ein kompromittierter Build-Job ist lokaler Code.

Für Android ist Bad Epoll bemerkenswert, weil viele Linux-LPEs dort nicht funktionieren: Android bringt bestimmte Module gar nicht mit oder blockiert typische Serverpfade. epoll ist anders. Der Forscher nennt Pixel-10-Geräte mit Kernel 6.6+ als PoC-Ziel für die UAF-Auslösung; ein vollständiger Android-Root-Exploit war zum geprüften Stand noch nicht veröffentlicht. Pixel 8 und andere v6.1-basierte Geräte stuft der Forscher als nicht betroffen ein, weil der Bug laut Write-up erst mit der 6.4-Linie kam.

Upstream-Fix und Kernelbereich

Bad Epoll wurde durch Commit 58c9b016e128 eingeführt, der am 08.04.2023 in den Kernel kam. Der Fix ist a6dc643c69311677c574a0f17a3f4d66a5f3744b, gelandet am 24.04.2026.

Für unveränderte Upstream-Kernel ist die grobe Regel:

Kernel-Kontext	Einordnung
vor 6.4	Laut Forscher-Write-up grundsätzlich nicht betroffen, sofern der verwundbare Commit nicht zurückportiert wurde.
6.4 bis vor gefixten Backports	Betroffen, wenn `a6dc643c6931` oder ein äquivalenter Backport fehlt.
6.18-Linie	NVD nennt `6.18.33` als nicht verwundbare Grenze für diese Linie.
7.0-Linie	NVD nennt `7.0.10` als nicht verwundbare Grenze.
7.1 und neuer	NVD führt 7.1 als Linie mit originalem Fix-Kontext.

Die NVD-Daten zeigen außerdem, warum eine einfache “unter 6.4 ist sicher”-Regel für Vendor-Kernel nicht genügt. NVD nennt zusätzlich verwundbare Semver-Bereiche ab 5.15.209 bis vor 5.16 und ab 6.1.175 bis vor 6.2. Das liegt an stabilen Backports und Vendor-Kernelpflege. Red Hat listet zum Beispiel RHEL 9 als betroffen, obwohl der Kernel dort nicht einfach wie ein Vanilla-6.4-Kernel aussieht.

Für produktive Systeme zählt deshalb nie nur uname -r. Entscheidend ist der Vendor-Tracker, der installierte Paketstand, der laufende Kernel nach Reboot und bei Livepatching der konkrete CVE-Nachweis.

Wer ist betroffen?

Die folgende Tabelle ist eine Momentaufnahme zum geprüften Stand. Sie ersetzt nicht den jeweiligen Vendor-Tracker.

Umgebung	Einschätzung	Worauf prüfen
Debian	Debian Bullseye und Bookworm sind laut Security Tracker nicht betroffen, weil der verwundbare Code nicht vorhanden ist. Trixie ist über Security ab `6.12.95-1` gefixt. Forky und Sid sind gefixt.	Debian Security Tracker, installierten Paketstand und laufenden Kernel prüfen. Bei Trixie auf Security-Kernel achten.
Ubuntu	Ubuntu bewertet CVE-2026-46242 als High. Die sichtbare `linux`-Tabelle markiert 26.04 LTS als “Vulnerable, work in progress”, 25.10 und 24.04 LTS als “Vulnerable”; 22.04 LTS, 20.04 LTS und ältere Standardkernel sind dort “Not affected”. Viele Cloud-, OEM-, HWE-, Realtime- und Spezialflavours stehen separat in der langen Tabelle.	Ubuntu-CVE-Seite pro Kernel-Flavour prüfen. `uname -r` allein reicht nicht, weil `linux-aws`, `linux-azure`, `linux-gcp`, `linux-oracle`, HWE, OEM und realtime eigene Tracks haben.
RHEL / Red Hat	Red Hat stuft die CVE als Moderate mit CVSS 7.0 ein und wählt wegen des Race-Fensters `AC:H`. RHEL 9 und 10 sind laut API betroffen. RHEL 7 und 8 sind nicht betroffen, RHEL 6 war zum geprüften Stand “Under investigation”. Red Hat nennt keine einfache Mitigation.	Red-Hat-CVE-Seite und Errata prüfen. Für RHEL 9/10 nicht auf Modul-Blocklists setzen.
AlmaLinux	In den öffentlich verlinkten `errata.full.json`-Feeds für AlmaLinux 8, 9 und 10 fand sich zum geprüften Stand kein Eintrag für CVE-2026-46242.	Alma-Errata, OVAL und `rpm -q --changelog kernel-core` prüfen. Alma 9/10 nicht einfach als “gefixt” behandeln, bis ein Advisory oder Changelog den Backport belegt.
Rocky Linux	Die Rocky-Errata-API enthielt zum geprüften Stand keinen Treffer für CVE-2026-46242.	Rocky-Errata, `dnf updateinfo`, Kernel-Changelog und laufenden Kernel prüfen. Bei Rocky 9/10 bis zum Beleg vorsichtig wie bei betroffenen EL9/10-Kerneln behandeln.
CloudLinux	Kein eigener öffentlicher Bad-Epoll-Artikel wie bei Copy Fail/Dirty Frag gefunden. Für CL9/CL10 ist wegen EL9/10-Nähe eine explizite KernelCare- oder Vendor-Prüfung nötig.	CloudLinux-Errata, KernelCare-Status und laufenden Kernel prüfen. Nicht aus älteren CloudLinux-Artikeln zu anderen CVEs ableiten.
Amazon Linux	AWS markiert Amazon Linux 2 und den AL2023-Standardkernel auf der CVE-Seite als nicht betroffen. AL2023 `kernel6.12` und `kernel6.18` stehen dort als Pending Fix; für `kernel6.18` gibt es gleichzeitig ALAS2023-2026-1866 mit Paketen `6.18.33-63.124`. ALAS2023-2026-1882 enthält außerdem den AL2023-Standardkernel `6.1.175-219.357` in einem Sammelupdate.	AWS-CVE-Seite und konkrete ALAS-Advisory pro Kerneltrack prüfen. Bei optionalen AL2023-Kerneln nicht vom Standardkernel-Status ausgehen.
SUSE / openSUSE	SUSE führt den Gesamtstatus als Pending und bewertet die eigene Severity als Moderate. openSUSE Tumbleweed hat Pakete ab `7.0.11-1.1`. Viele SLE 15 SP6/SP7, SLE 16, SLE Micro 6.0/6.1/6.2, Leap 15.6 und Leap 16.0-Stände sind als affected geführt. Ältere SLE 12/15 SP4/SP5- und Micro-5.x-Stände sind häufig not affected.	Produktgenaue SUSE-CVE-Seite prüfen. SUSE-Status “Affected”, “Released”, “Not affected” und Service-Pack-Lifecycle nicht vermischen.
Fedora / Fedora CoreOS	Kein belastbarer, CVE-getaggter Bodhi-Treffer im schnellen Check. Wegen aktueller Kernel-Linien ist Fedora grundsätzlich genau zu prüfen.	`dnf update 'kernel*'`, Bodhi, Fedora-Kernel-Changelog und `uname -r` abgleichen. Nicht bei einem 7.0-Kernel vor `7.0.10` stehen bleiben, wenn kein Backport belegt ist.
Oracle Linux	Zum geprüften Stand war keine Oracle-CVE-Seite für CVE-2026-46242 sichtbar. RHCK und UEK können unterschiedlich betroffen sein.	`uname -r`, `rpm -q kernel kernel-uek`, Oracle ELSA/CVE und Ksplice-Status getrennt prüfen.
Proxmox VE	Kein Proxmox-PSA für CVE-2026-46242 gefunden. PVE-8-/PVE-9-Kernel auf 6.8, 6.14, 6.17 oder 7.0 müssen gegen Proxmox-Changelogs und Upstream-Fix abgeglichen werden.	`pveversion -v`, installierte `proxmox-kernel`/`pve-kernel`-Pakete, laufenden Kernel und Proxmox-Changelogs prüfen. LXC-Hosts priorisieren.
Plesk-Server	Plesk selbst ist nicht der Bug. Entscheidend ist der darunterliegende OS-Kernel. Plesk-Hosts sind praktisch relevant, weil dort oft mehrere Kunden-, Web- und Systembenutzer laufen.	OS-Vendor-Kernel, KernelCare falls vorhanden, Reboot-Status und lokale Mandantentrennung prüfen.
Docker, Kubernetes, CI-Runner	Sehr relevant, wenn fremder oder weniger vertrauenswürdiger Code läuft. Container teilen den Host-Kernel.	Node-Kernel patchen, Workloads drainen oder pausieren, CI-Runner aus der Queue nehmen, Reboot dokumentieren.
Android	Nach Forscherangaben sind v6.1-basierte Geräte wie Pixel 8 nicht betroffen. Pixel 10 beziehungsweise v6.6+-Geräte sind im PoC-Kontext relevant; ein vollständiger Android-Root-Exploit war zum geprüften Stand noch in Arbeit.	Hersteller-Security-Bulletins, Android-Security-Patch-Level und konkrete Kernelbasis prüfen.
Single-Tenant-Server ohne fremden Code	Geringeres Risiko, aber nicht “nicht betroffen”. Eine kompromittierte Anwendung ist lokaler Code.	Normal priorisiert patchen, aber bei öffentlichem Exploit nicht auf den nächsten Quartalstermin schieben.

Patchstände nach Distribution

Für die direkte Prüfung sind diese Stände besonders wichtig:

Distribution / Plattform	Stand zum geprüften Zeitpunkt
Debian Bullseye	Laut Debian-Tracker nicht betroffen. Die Tabelle führt Bullseye/Bullseye Security als fixed beziehungsweise not affected, weil der verwundbare Code nicht vorhanden ist.
Debian Bookworm	Laut Debian-Tracker nicht betroffen.
Debian Trixie	Verwundbar in der Basistabelle bei `6.12.86-1`, gefixt über Trixie Security ab `6.12.95-1` mit DSA-6381-1.
Debian Forky / Sid	Forky `7.0.13-1`, Sid `7.1.3-1` als fixed geführt; der Tracker nennt außerdem `7.0.10-1` als unstable-Fixgrenze.
Ubuntu `linux`	26.04 LTS: vulnerable/work in progress. 25.10: vulnerable. 24.04 LTS: vulnerable. 22.04 LTS und ältere Standardkernel: not affected.
Ubuntu Spezialkernel	Lange Ubuntu-Tabelle separat prüfen. Sichtbar sind mehrere vulnerable Cloud-, OEM-, HWE-, realtime-, Oracle-, NVIDIA-, Xilinx- und RISC-V-Tracks.
RHEL 9 / 10	Red-Hat-CVE-API: affected. Keine einfache Mitigation.
RHEL 7 / 8	Red-Hat-CVE-API: not affected.
AlmaLinux 8 / 9 / 10	Kein CVE-2026-46242-Eintrag in den geprüften Alma-Errata-Feeds. Das ist kein Fix-Nachweis für 9/10.
Rocky Linux 8 / 9 / 10	Kein CVE-2026-46242-Treffer in der geprüften Rocky-Errata-API. Das ist kein Fix-Nachweis für 9/10.
Amazon Linux 2	AWS-CVE-Seite: nicht betroffen für Core, Kernel-5.4, Kernel-5.10 und Kernel-5.15 Extra.
Amazon Linux 2023	AWS-CVE-Seite: Standardkernel nicht betroffen; `kernel6.12` und `kernel6.18` Pending Fix. ALAS2023-2026-1866 liefert aber ein `kernel6.18`-Update auf `6.18.33-63.124`, ALAS2023-2026-1882 ein Standardkernel-Sammelupdate auf `6.1.175-219.357`.
SUSE / openSUSE	openSUSE Tumbleweed ab `kernel-source >= 7.0.11-1.1` released. Viele SLE-15-SP6/SP7-, SLE-16-, Micro-6.x- und Leap-15.6/16.0-Produkte sind affected; ältere SPs teils not affected.
Proxmox VE	Kein eigener PSA-Fixstand sichtbar. PVE-Kernel gegen Proxmox-Changelog und Upstream-Fix `a6dc643c6931` prüfen.

Diese Tabelle ist absichtlich vorsichtig. Gerade bei Bad Epoll wäre es fahrlässig, aus der Upstream-Version allein einen Vendor-Status zu bauen. Enterprise-Distributionen backporten Features, Fixes und manchmal auch Regressionen. Deshalb kann ein 5.14- oder 6.1-basierter Vendor-Kernel anders bewertet werden als ein sauberer Vanilla-Kernel derselben Hauptlinie.

Schnelle Prüfung auf einem Host

Zuerst brauchst du den laufenden Kernel:

uname -r
uname -a

Dann prüfst du installierte Kernelpakete. Debian, Ubuntu und Proxmox:

dpkg -l 'linux-image*' 'linux-modules*' 'proxmox-kernel*' 'pve-kernel*' 2>/dev/null | awk '/^ii/ {print $2, $3}'

RHEL, Rocky, AlmaLinux, CloudLinux, Oracle und Fedora:

rpm -q kernel kernel-core kernel-modules kernel-modules-extra kernel-uek 2>/dev/null
uname -r

SUSE und openSUSE:

zypper se -si 'kernel*'
uname -r

Proxmox zusätzlich:

pveversion -v
dpkg -l 'proxmox-kernel*' 'pve-kernel*' | awk '/^ii/ {print $2, $3}'
apt-cache policy proxmox-kernel-6.8 proxmox-kernel-6.14 proxmox-kernel-6.17 proxmox-kernel-7.0 2>/dev/null

Bei Bad Epoll gibt es keinen aussagekräftigen “ist das Modul geladen?”-Check. epoll ist normalerweise fest im Kernel. Wenn die Kernel-Konfiguration verfügbar ist, kannst du nur bestätigen, dass epoll grundsätzlich vorhanden ist:

grep CONFIG_EPOLL "/boot/config-$(uname -r)" 2>/dev/null || true
zgrep CONFIG_EPOLL /proc/config.gz 2>/dev/null || true

Für Vendor-Backports ist der Changelog oft hilfreicher. Debian/Ubuntu:

zgrep -Ei 'CVE-2026-46242|a6dc643c6931|eventpoll|ep_remove' /usr/share/doc/linux-image-*/changelog* 2>/dev/null | head -40

RHEL-nahe Systeme:

rpm -q --changelog kernel-core 2>/dev/null | grep -Ei 'CVE-2026-46242|a6dc643c6931|eventpoll|ep_remove' | head -40

Das ist kein vollständiger Vulnerability-Scanner. Es beantwortet aber die ersten Betriebsfragen:

Welcher Kernel läuft wirklich?
Welcher Kernel ist installiert?
Gibt der Vendor diesen Kernel als betroffen, gefixt oder nicht betroffen an?
Gibt es lokale Workloads, bei denen ein begrenzter Einstieg realistisch ist?

Updates einspielen

Die saubere Lösung ist ein Kernel-Update aus dem passenden Vendor-Repository. Danach muss der Host rebooten, außer ein Livepatch weist CVE-2026-46242 für exakt den laufenden Kernel nach.

Debian, Ubuntu und Proxmox:

sudo apt update
sudo apt full-upgrade
sudo reboot
uname -r

RHEL, Rocky, AlmaLinux, CloudLinux und Fedora:

sudo dnf clean metadata
sudo dnf update 'kernel*'
sudo reboot
uname -r

Bei älteren EL-Systemen kann noch yum statt dnf relevant sein.

SUSE und openSUSE:

sudo zypper refresh
sudo zypper patch
sudo reboot
uname -r

Amazon Linux 2023 mit optionalem Kerneltrack:

sudo dnf update kernel kernel6.12 kernel6.18 2>/dev/null
sudo reboot
uname -r

Für kernel6.18 verweist ALAS2023-2026-1866 konkret auf:

sudo dnf update kernel6.18 --releasever 2023.12.20260622

Das ist nur sinnvoll, wenn dein System diesen Track wirklich nutzt. Sonst aktualisierst du ein Paket, das nicht der laufende Kernel ist.

Livepatching musst du mit dem jeweiligen Tool belegen. uname -r bleibt beim Livepatching normalerweise gleich:

canonical-livepatch status --verbose 2>/dev/null || true
kpatch list 2>/dev/null || true
kcarectl --patch-info 2>/dev/null | grep -Ei 'CVE-2026-46242|bad.?epoll|eventpoll|ep_remove' || true
uptrack-show --available 2>/dev/null || true

Nach dem Wartungsfenster gehört die Nachkontrolle dazu:

echo "Laufender Kernel: $(uname -r)"

Und dann gegen den Vendor-Fixstand halten. Ein installiertes Kernelpaket ist kein Fix, wenn der Host weiter mit dem alten Kernel läuft.

Was tun, wenn noch kein Fix verfügbar ist?

Bei Bad Epoll ist die ehrliche Antwort unangenehm: Es gibt keinen sauberen, generischen Workaround.

Diese Maßnahmen können Risiko reduzieren, ersetzen aber keinen Fix:

untrusted CI-Runner pausieren oder auf bereits gefixte Worker verschieben
Kubernetes-Nodes mit gemischten Trust-Zonen priorisiert patchen und drainen
Shared-Hosting- und Plesk-Systeme mit Kunden-Shells vor Single-Tenant-Systemen patchen
LXC-lastige Proxmox-Hosts priorisieren
unnötige lokale Benutzer und alte SSH-Zugänge deaktivieren
Build-Jobs aus Pull Requests oder fremden Repositories einschränken
Browser- und Desktop-Systeme mit hohem Web-/Plugin-Risiko zeitnah aktualisieren

Nicht ausreichend:

user.max_user_namespaces=0 als alleinige Maßnahme. Der Forscher nennt ausdrücklich keine User-Namespace-Anforderung.
Modul-Blocklists. Es gibt kein bad_epoll.ko, das man entladen könnte.
Container-Image-Updates. Container teilen den Host-Kernel.
Nur CVE-2026-43074 prüfen. Das ist der verwandte epoll-Bug, aber nicht dieser Fix.

Seccomp-Profile, die epoll_create, epoll_ctl oder epoll_wait blockieren, brechen in normalen Linux-Workloads sehr schnell legitime Software. Für eng kontrollierte Spezial-Sandboxes kann das eine Option sein. Für Server, Container-Hosts und Desktops ist das keine praktikable Standard-Mitigation.

Einordnung für Plesk, Proxmox und Hosting

Für Plesk-Server ist Bad Epoll relevant, wenn mehrere Kunden, Website-Benutzer, Cronjobs, PHP-FPM-Pools, Deployment-Prozesse oder Shell-Zugänge auf demselben Host laufen. Plesk patcht hier nicht den Kernel. Der darunterliegende Debian-, Ubuntu-, Alma-, Rocky-, CloudLinux- oder RHEL-Kernel entscheidet.

Bei Proxmox ist die Trennung wie immer wichtig:

Proxmox-Host: Der Host-Kernel muss bewertet werden. Backup-Hooks, Storage-Tools, Automatisierung und Admin-Shells laufen direkt auf dem Host.
LXC-Container: LXC teilt den Host-Kernel. Wenn der Host verwundbar ist, ist der Container-Kontext relevant.
KVM-VMs: KVM-Gäste haben eigene Guest-Kernel. Sie müssen separat gepatcht werden. Ein exploitbarer Guest-Kernel ist nicht automatisch der Proxmox-Host.
Cluster: Reboots brauchen Reihenfolge. Nodes drainen, HA-Workloads migrieren oder kontrolliert stoppen, danach den laufenden Kernel dokumentieren.

Für Hoster, Agenturen und MSPs ist die Priorisierung recht klar: Systeme mit fremdem oder weniger vertrauenswürdigem Code zuerst. Dazu gehören Shared Hosting, Build-Server, GitLab Runner, Kubernetes-Nodes, Docker-Hosts mit Kundenworkloads und Proxmox-Hosts mit LXC-Containern, die nicht vollständig unter eigener Kontrolle stehen.

Was beim Patchen gern übersehen wird

Der häufigste Fehler ist ein Kernelupdate ohne Reboot. Danach liegt der Fix auf der Platte, aber der alte Kernel läuft weiter.

Der zweite Fehler ist die falsche Fix-Annahme über die Kernelhauptversion. Bei Bad Epoll ist das besonders tückisch, weil der Forscher v6.4+ als grobe Linie nennt, NVD aber einzelne stabile Backportbereiche aufführt und Red Hat RHEL 9 als betroffen bewertet. Vendor-Kernel sind keine Vanilla-Kernel.

Der dritte Fehler ist ein falsch verstandener Workaround. User-Namespaces, Modul-Blocklists und act_pedit-Regeln gehören zu anderen Lücken. Bei Bad Epoll hilft nur Patchen, Livepatching oder das Reduzieren lokaler Ausführungsrisiken bis zum Patch.

Der vierte Fehler ist “Container aktualisiert, Host vergessen”. Ein Alpine-, Debian- oder Ubuntu-Container bringt keinen eigenen Kernel mit. Der Node entscheidet.

Der fünfte Fehler ist fehlender Fallback. Gerade bei Proxmox, ZFS-Boot, Secure Boot und älteren Bare-Metal-Systemen sollte ein bekannter bootfähiger Kernel erhalten bleiben, bis der neue Kernel einmal sauber gebootet hat und Netzwerk, Storage, Cluster und Backups geprüft sind.

Wie wir damit umgehen würden

Bei einem produktiven Setup wäre die Reihenfolge pragmatisch:

Hostliste aus Monitoring, Inventar, Proxmox, Cloud und Plesk ziehen.
Systeme nach Risiko sortieren: Shared Hosting, Container, CI, Shell-Zugänge, Desktops mit hohem Browser-Risiko zuerst.
Pro Host laufenden Kernel und installierte Kernelpakete erfassen.
Vendor-Tracker gegen Debian, Ubuntu, Red Hat, SUSE, Amazon Linux, Alma, Rocky, CloudLinux, Proxmox und Oracle prüfen.
Wenn kein Fix verfügbar ist: lokale Ausführungsmöglichkeiten reduzieren und Wartungsfenster priorisieren.
Kernelupdate oder Livepatch einspielen.
Reboot oder Livepatch-Nachweis dokumentieren.
Nachkontrolle: laufender Kernel, Paketstand, Monitoring, offene Hosts.
Bei Verdacht auf Ausnutzung nicht nur patchen, sondern Incident-Response starten.

Wenn du nicht sicher bist, ob deine Server betroffen sind, ist ein kurzer Security- und Kernel-Check sinnvoller als ein PoC-Test auf Produktion. Gerade bei Plesk-, Proxmox-, Container- und CI-Umgebungen ist die Frage nicht nur “Update ja/nein”, sondern “welcher Host kann wann rebooten, welcher Kernel läuft danach wirklich, und wo läuft fremder Code?”

Update-Log

2023-04-08: Der verwundbare epoll-Refcount-Commit 58c9b016e128 wurde in den Kernel aufgenommen.
2026-02-11: Jaeyoung Chung erlangte laut Write-up kernelCTF-Flags auf lts-6.12.67 und cos-121-18867.294.100.
2026-02-17: Die Lücke wurde an security@kernel.org gemeldet. Ein erster Patch-Prototyp war laut Timeline nicht korrekt.
2026-04-02: Der verwandte epoll-Bug CVE-2026-43074 wurde in Mainline gefixt. Der verbleibende struct file-UAF von Bad Epoll blieb bestehen.
2026-04-22: Der verbleibende UAF wurde erneut gemeldet.
2026-04-24: Der Fix a6dc643c6931 landete in Mainline.
2026-05-30: CVE-2026-46242 wurde durch kernel.org/NVD öffentlich sichtbar.
2026-07-03: Breitere öffentliche Berichte zu “Bad Epoll” erschienen, unter anderem mit Verweis auf Android- und Chrome-Sandbox-Relevanz.
2026-07-06: Artikel angelegt. Debian-, Ubuntu-, Red-Hat-, SUSE-, Alma-, Rocky- und Amazon-Linux-Stände gegen öffentlich verfügbare Tracker und Feeds geprüft.