Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Suchen Sie nach Maßnahmen zur Risikominderung? Weiter unten ↓
Die Kurzfassung
- Was: Eine Kette zur Ausweitung lokaler Privilegien unter Linux mit dem Namen „Dirty Frag“, die CVE-2026-43284 (xfrm-ESP-Page-Cache-Write) und CVE-2026-43500 (RxRPC-Seiten-Cache-Schreiben).
- Auswirkungen: Öffentlich zugängliche Proof-of-Concept-Exploits zeigen, dass auf anfälligen Kerneln eine zuverlässige Eskalation der Root-Rechte von einem lokalen Konto ohne Sonderrechte möglich ist.
- Status: Es sind funktionierende öffentliche Exploits im Umlauf. Die Sperrfrist wurde vor Abschluss der koordinierten Patches aufgehoben.
- Schweregrad: Lokaler Angriffsvektor, geringe Komplexität, keine Benutzerinteraktion, deterministische Ausnutzung. CVSS: 7,8 (vorläufig)
- Handeln Sie jetzt:Schützen Siebetroffene Kernel unverzüglich. Durch das Patchen ohne Neustart lässt sich „Dirty Frag“ beheben, ohne auf Wartungsfenster oder Neustarts warten zu müssen. Andernfalls sollten Sie gepatchte Kernel so schnell wie möglich bereitstellen. Falls beides nicht sofort möglich ist, deaktivieren Sie vorübergehend die unten aufgeführten anfälligen ESP- und RxRPC-Pfade.
Bin ich betroffen?
Sie sind wahrscheinlich betroffen, wenn Sie einen aktuellen, vom Mainline-Kernel abgeleiteten Kernel auf einem der folgenden Systeme betreiben:
- Ubuntu (LTS und aktuelle Versionen)
- Red Hat Enterprise Linux, AlmaLinux, Rocky Linux, CentOS Stream
- Fedora
- openSUSE Tumbleweed
- Die meisten nachgelagerten Rebuilds, einschließlich CloudLinux-Varianten
Schnellüberprüfung der freiliegenden Module:
lsmod | grep -E '^(esp4|esp6|rxrpc)'
Sollte eine dieser Komponenten geladen sein – oder von einem Benutzer ohne Sonderrechte bei Bedarf automatisch geladen werden können –, sollten Sie den Host so lange als gefährdet betrachten, bis ein Patch installiert wurde.
Du bist nicht automatisch sicher, nur weil du dich früher beworben hast Kopieren fehlgeschlagen Abwehrmaßnahmen. Blockieren algif_aead stoppt Dirty Frag nicht.
Was ist „Dirty Frag“?
„Dirty Frag“ ist eine Kette zur lokalen Privilegienausweitung (LPE) im Kernel, die zwei integrierte Entschlüsselungspfade im Linux-Netzwerkstack ausnutzt:
- xfrm-ESP (esp4, esp6), verwendet von IPsec
- RxRPC (rxrpc), verwendet von AFS und zugehörigem RPC-Datenverkehr
Er gehört zur gleichen Fehlerfamilie wie „Dirty Pipe“ und „Copy Fail“: Eine Kernel-Routine schreibt Daten in eine Seite, über die sie nicht die alleinige Kontrolle hat, und überschreibt dadurch den Inhalt eines Page-Cache-Eintrags, der eine Datei auf der Festplatte abdeckt.
Die Kette wurde vom Forscher Hyunwoo Kim veröffentlicht. ‘Copy Fail 2: Electric Boogaloo“ ist die xfrm-ESP-Hälfte von Dirty Frag (CVE-2026-43284), die aus dem öffentlichen Fix-Commit rückentwickelt wurde – es handelt sich nicht um eine separate CVE und nicht um die vollständige Kette.
Wie der Exploit tatsächlich funktioniert
Der Linux-Seiten-Cache speichert Kopien von Dateiinhalten im Arbeitsspeicher, sodass wiederholte Lesevorgänge nicht auf die Festplatte zurückgreifen müssen. Wenn Sie cat /etc/passwd, liefert der Kernel Ihnen fast immer Bytes aus einer zwischengespeicherten Seite und nicht aus dem Dateisystem. Diese zwischengespeicherte Seite wird gemeinsam genutzt: Jeder Leser dieser Datei sieht denselben Speicherinhalt.
Moderne Kernel-Empfangspfade unterstützen Zero-Copy- Entschlüsselung. Wenn verschlüsselte Netzwerkdaten eintreffen – zum Beispiel ein ESP-gekapseltes IPsec-Paket – kann der Kernel diese direkt in eine Zielseite entschlüsseln, anstatt einen neuen Puffer zuzuweisen und zweimal zu kopieren. Dies ist schnell und für die meisten Ziele sicher, da die Zielseite vom Kernel eigens für diesen Zweck zugewiesen wurde.
Ein „Dirty Frag“ entsteht, wenn die Zielseite nicht in Privatbesitz ist. Durch sorgfältig konstruierte splice(2) oder sendfile(2) kann ein nicht privilegierter Prozess dafür sorgen, dass der ESP- oder RxRPC-Empfangspfad des Kernels eingehende Daten direkt in eine Seite entschlüsselt, die derzeit im Seiten-Cache liegt – einschließlich Seiten, die sensible Dateien wie /etc/passwd oder /usr/bin/su.
Die entschlüsselten Bytes werden vom Angreifer kontrolliert (der Angreifer hat den Klartext vor der Verschlüsselung und dem Versand ausgewählt). Da der Kernel die Zielseite weder mittels COW noch auf andere Weise isoliert, landet der Schreibvorgang in der gemeinsam genutzten Kopie im Seiten-Cache. Nachfolgende Lesevorgänge der Datei – einschließlich Lesevorgänge durch login, sudooder su – geben den geänderten Inhalt zurück.
Die Datei auf der Festplatte bleibt unverändert. Bei nachfolgenden Lesevorgängen wird jedoch möglicherweise die geänderte Version aus dem Cache anstelle des ursprünglichen Dateisysteminhalts verwendet.
Zur Abdeckung des Vertriebsnetzes werden zwei Pfade miteinander verknüpft:
- Der ESP-Pfad erfordert die Erstellung eines Namespace für nicht privilegierte Benutzer, was Ubuntu über AppArmor blockiert, die meisten anderen Distributionen dies jedoch zulassen.
- Der RxRPC-Pfad erfordert das Laden des Moduls rxrpc.ko, das in den meisten Distributionen standardmäßig nicht enthalten ist – in Ubuntu jedoch schon. Der Namespace-Block von Ubuntu wird von RxRPC abgedeckt; das fehlende rxrpc bei allen anderen wird von ESP abgedeckt.
Zusammen decken sie die gängigsten Hardening-Konfigurationen ab.
Was diesen Fehler in der Praxis so besonders gefährlich macht:
- Deterministisch: Kein Race-Fenster, keine zeitkritische Primitive.
- Keine Fehlermeldung: Fehlgeschlagene Versuche versetzen den Kernel in der Regel nicht in Panik.
- Hohe Erfolgsquote: Zuverlässig genug, dass der öffentliche PoC auf Anhieb funktioniert.
- Schnelle Ausnutzung von Sicherheitslücken: Öffentliche Exploit-Ketten tauchten auf, noch bevor koordinierte Patches fertiggestellt waren, wodurch sich die Reaktionszeit der Verteidiger drastisch verkürzte.
Milderung
Der sicherste Weg zur Behebung des Problems besteht darin, den laufenden Kernel unverzüglich zu schützen. Es gibt drei praktische Möglichkeiten, das Risiko zu verringern; diese sind hier nach Geschwindigkeit und Auswirkungen auf den Betrieb geordnet.
1. Patches ohne Neustart (am schnellsten, keine Ausfallzeiten)
Für betroffene Enterprise-Kernel-Familien werden derzeit „KernelCare“-Patches ohne Neustart bereitgestellt, wodurch anfällige, aktiv laufende Kernel geschützt werden können, ohne dass auf Notfall-Wartungsfenster oder koordinierte Neustarts gewartet werden muss.
Für Unternehmen, die eine verfügbarkeitskritische Infrastruktur betreiben, verkürzt dies die Behebungszeit sofort, während die regulären Kernel-Updates und Neustartzyklen der Anbieter nachziehen.
Wenn weitere Versionen von nachgelagerten Kernel-Paketen veröffentlicht werden, kann es vorübergehend zu Verzögerungen bei der Erkennung von Scannern und der Meldung von Hersteller-Versionen im Vergleich zum geschützten Betriebszustand des Kernels kommen.
| Sie sind noch kein KernelCare-Kunde? Bis Ende Juni gelten für Neukunden Sonderkonditionen. Erfahren Sie hier mehr über KernelCare. |
2. Installieren Sie einen gepatchten Kernel und starten Sie den Computer neu
Die übliche Vorgehensweise zur Behebung des Problems besteht darin, die vom Hersteller bereitgestellten gepatchten Kernel-Pakete zu installieren und die betroffenen Systeme so bald wie betrieblich möglich neu zu starten.
Legen Sie den Schwerpunkt auf Systeme, in denen teilweise vertrauenswürdiger Code ausgeführt werden kann – darunter Kubernetes-Knoten, CI/CD-Runner, Shared-Hosting-Umgebungen, Entwicklerinfrastruktur und mandantenfähige Workloads.
3. Vorübergehende manuelle Abhilfe (falls das Installieren des Patches noch warten muss)
Falls weder Patches ohne Neustart noch Fenster für einen sofortigen Neustart verfügbar sind, können die anfälligen ESP- und RxRPC-Pfade durch das Sperren von Modulen vorübergehend deaktiviert werden.
Bitte lesen Sie dies zuerst
Das Blockieren von esp4 und esp6 führt zu einer Unterbrechung von IPsec. Wenn Sie IPsec-Datenverkehr terminieren oder weiterleiten – beispielsweise strongSwan, Libreswan, Site-to-Site-VPNs oder Road-Warrior-Clients –, führt die Anwendung dieser Einstellung auf Produktionsservern dazu, dass diese Tunnel unterbrochen werden.
Vergewissern Sie sich vor einer flächendeckenden Bereitstellung, dass die Module nicht aktiv genutzt werden.
ip xfrm policy list 2>/dev/null | head
ss -tunap | grep -i rxrpc
Wenn die Ausgabe nicht leer ist, sollten Sie die Auswirkungen berücksichtigen, bevor Sie fortfahren.
Die anfälligen Module blockieren
sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"
Wenn der Verdacht auf eine Kompromittierung besteht
Leeren Sie den Seitencache, damit alle geänderten zwischengespeicherten Binärdateien entfernt und beim nächsten Zugriff erneut von der Festplatte geladen werden:
sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
Betrachten Sie dies als forensischen Schritt, nicht als Lösung. Falls ein Angreifer über „Dirty Frag“ bereits Root-Rechte erlangt hat, werden durch das Leeren des Seiten-Caches keine Daten entfernt, die er nach der Rechteausweitung erstellt hat.
Erkennung
Derzeit gibt es keine allgemein anerkannte oder zuverlässige Methode zur nachträglichen Erkennung, mit der sich eine erfolgreiche Ausnutzung von „Dirty Frag“ bestätigen lässt. Die Dateien auf der Festplatte bleiben unberührt, und der Angriff hinterlässt keine so eindeutigen Syscall-Muster wie „Dirty Pipe“. Dennoch lohnt es sich, nach einigen Anzeichen Ausschau zu halten:
- Unerwartetes Laden von esp4, esp6oder rxrpc auf Hosts, die nichts mit IPsec oder AFS zu tun haben. Auditd-Regel:
-w /sbin/modprobe -p x -k module_load
- Neuanlage von Netzwerk-Namespaces durch nicht privilegierte Benutzer auf Systemen, auf denen dies nicht zum normalen Arbeitsaufkommen gehört. Nachverfolgung über unshare Syscalls oder eBPF.
- Ausführung von Setuid-Befehlen durch Konten, die diese Funktion zuvor noch nie aufgerufen haben su oder sudoaufgerufen haben, insbesondere kurz nach intensiver Nutzung von splice/sendfile.
- Kunden von Imunify360: Indikatoren, die mit dem Bereitstellungsskript des öffentlichen PoC in Verbindung stehen, wurden in die Blockliste aufgenommen.
Dies sind lediglich Richtwerte, keine Garantien. Gehen Sie davon aus, dass jeder Host, auf dem ein nicht vertrauenswürdiger lokaler Benutzer während des Zeitfensters Zugriff auf die Shell hatte, potenziell kompromittiert ist.
Checkliste für priorisierte Sanierungsmaßnahmen
- Patch: Wenden Sie einen Patch ohne Neustart an oder stellen Sie einen gepatchten Kernel sofort bereit. KernelCare-Benutzer können unterstützte, laufende Kernel ohne Neustart schützen, während die regulären Wartungsfenster nachholen. Andernfalls installieren Sie vom Hersteller gepatchte Kernel und starten Sie die betroffenen Systeme so schnell wie möglich neu.
- Wenn Sie nicht sofort ein Patch installieren können, wenden Sie die oben beschriebene Abhilfemaßnahme zum Blockieren des Moduls an – nachdem Sie sich vergewissert haben, dass Sie nicht auf IPsec oder RxRPC angewiesen sind.
- Lokalen Zugriff prüfen: Überprüfen Sie, wer derzeit Shell-Zugriff auf Shared Hosts, CI/CD-Runner, Build-Server und Multi-Tenant-Systeme hat. Entziehen Sie die Berechtigungen, die für diesen Zeitraum nicht benötigt werden.
- Suche: Führen Sie die oben genannten Erkennungsabfragen für das Expositionsfenster aus.
- Neustart nach dem Patchen: Dadurch werden alle möglicherweise geänderten zwischengespeicherten Seiten zusammen mit dem alten Kernel gelöscht.
Warum Fehler wie „Dirty Frag“ schneller auftreten
„Dirty Frag“ spiegelt zudem einen allgemeinen Branchentrend wider: KI-gestützte Prüfungen beschleunigen die Aufdeckung tiefgreifender, langlebiger Fehler in leistungskritischen Codepfaden.
In einem kürzlich veröffentlichten Beitrag argumentierte Igor Seletskiy, CEO von TuxCare, dass moderne KI-gestützte Analysen die Zeit drastisch verkürzen, die erforderlich ist, um subtile Schwachstellen im Kernel und in der Infrastruktur aufzudecken, die zuvor jahrelangen Überprüfungen standgehalten hatten.
„Dirty Frag“ entspricht genau diesem Muster: eine Schwachstelle bei der Seiten-Cache-Zugehörigkeit, die in Hochleistungs-Netzwerkpfaden verborgen ist und nun für eine zuverlässige Rechteausweitung missbraucht wird, wofür bereits öffentlicher Exploit-Code im Umlauf ist.
Referenzen
CVE-2026-43284 (xfrm-ESP Page-Cache Write) – NVD-Eintrag: https://nvd.nist.gov/vuln/detail/CVE-2026-43284
CVE-2026-43500 (RxRPC-Seiten-Cache-Schreibzugriff) – NVD-Eintrag: https://nvd.nist.gov/vuln/detail/CVE-2026-43500
- Hinweis: Der Eintrag „RxRPC“ ist für die Nachverfolgung reserviert, da der NVD-Eintrag noch veröffentlicht werden muss. Daher wird die Seite möglicherweise als „RESERVIERT“ angezeigt, bis sie mit Daten gefüllt ist.
Originalbeitrag des Forschers – Hyunwoo Kim (@v4bel):
- Gehostete Website: https://dirtyfrag.io
- Vollständiger technischer Bericht auf GitHub: https://github.com/V4bel/dirtyfrag/blob/master/assets/write-up.md
- PoC-Repo / README: https://github.com/V4bel/dirtyfrag
- E-Mail zur Offenlegung von Sicherheitslücken (7. Mai 2026): https://www.openwall.com/lists/oss-security/2026/05/07/8
Vorherige Kernel-Patch-Reihe (lore.kernel.org):
- RxRPC-Patch-Thread (auf den im AlmaLinux-Hinweis verwiesen wird): https://lore.kernel.org/all/afKV2zGR6rrelPC7@v4bel/
- Für den zusammengeführten ESP-Fix lautet die kanonische Commit-Referenz „mainline“ f4c50a4034e6: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=f4c50a4034e62ab75f1d5cdd191dd5f9c77fdff4
AlmaLinux-Hinweis: https://almalinux.org/blog/2026-05-07-dirty-frag/
