Fragnesia (CVE-2026-46300): Eine neue LPE-Schwachstelle im Linux-Kernel aus der „Dirty Frag“-Familie

Die Kurzfassung

Was: Eine Schwachstelle in der XFRM-ESP-in-TCP-Verarbeitung des Linux-Kernels ermöglicht es einem lokalen Benutzer ohne Sonderrechte, kontrollierte Änderungen an zwischengespeicherten Seiten von schreibgeschützten Dateien, einschließlich setuid-Binärdateien, herbeizuführen.

Auswirkung: Lokale Rechteausweitung auf Root durch Manipulation des Seiten-Caches. Die Datei auf der Festplatte bleibt unverändert, während die im Speicher befindliche zwischengespeicherte Kopie verändert wird.

Betroffene Systeme: Systeme, auf denen die betroffenen skbuff-Codepfade ausgeführt werden, einschließlich Kernel, die bereits den „Dirty Frag“-Fix erhalten haben. Der öffentliche PoC benötigt CONFIG_INET_ESPINTCP, um den Fehler auszulösen; daher blockieren Kernel, die ohne diese Option kompiliert wurden, diesen Exploit. Der zugrunde liegende skbuff-Fehler kann jedoch möglicherweise über andere Pfade erreicht werden. Distributionen, die standardmäßig die Namespaces nicht privilegierter Benutzer einschränken (wie beispielsweise die AppArmor-Konfiguration von Ubuntu), blockieren den öffentlichen PoC teilweise.

Status des Exploits: Öffentlicher PoC unmittelbar nach der Offenlegung auf GitHub veröffentlicht.

CVE ID: CVE-2026-46300

Abhilfemaßnahmen: Deaktivieren Sie anfällige ESP-Module oder installieren Sie Patches des Herstellers bzw. Live-Patches, sobald diese verfügbar sind.

Status der KernelCare-Abdeckung (aktualisiert am 18.05.2026, 13:00 UTC): Patches ohne Neustart sind in den Main- und ePortal-Feeds für AlmaLinux ELS/FIPS, Debian 11, Debian 12, die EL8-Familie, Rocky Linux 10, Oracle Linux 8, Oracle Linux 8 UEK 7, Oracle Linux 9, Oracle Linux 9 UEK 7, Ubuntu 22.04 (Jammy) und Ubuntu 24.04 (Noble) verfügbar.

kcarectl --update # pulls the patch if your kernel is in scope
kcarectl --patch-info | grep cve-2026-46300

Offenlegungsstatus: Technische Details, Hinweise zu betroffenen Versionen und Empfehlungen zur Risikominderung können sich ändern, sobald Anbieter Sicherheitshinweise veröffentlichen und nachgelagerte Kernel-Betreuer Backports fertigstellen.

Vor fünf Tagen hat Linux Korrekturen für „Dirty Frag“ veröffentlicht. Heute haben Sicherheitsteams es mit einem weiteren Exploit aus demselben Bereich zu tun.

Fragnesia (CVE-2026-46300) ist eine neu bekannt gewordene Sicherheitslücke zur lokalen Rechteausweitung, die auf das XFRM-ESP-in-TCP-Subsystem des Linux-Kernels abzielt. Sie wurde heute von William Bowling in Zusammenarbeit mit dem V12 Security-Team zusammen mit einem funktionierenden Proof-of-Concept veröffentlicht, der /usr/bin/su über den Seitencache überschreibt und Root-Zugriff ermöglicht.

Die Veröffentlichung erschien auf GitHub und X veröffentlicht, unmittelbar nachdem der Patch in der netdev-Mailingliste erschienen war, ohne Sperrfrist. Zum Zeitpunkt der Veröffentlichung wurde noch keine CVE-Nummer vergeben, und der vorgeschlagene Upstream-Fix befindet sich auf netdev und wartet auf Überprüfung und Zusammenführung.

Was „Fragnesia“ so bemerkenswert macht, ist nicht nur der Exploit selbst, sondern auch der Zeitpunkt und die Herkunft. Der vorgeschlagene Folge-Patch (eingereicht von Bowling) verweist ausdrücklich auf den „Dirty Frag“-Fix (f4c50a4034e6) als einen von zwei Commits, die er „behebt“ – was bedeutet, dass die ursprüngliche Behebung von „Dirty Frag“ einen zuvor latenten Fehler auf eine Weise aufgedeckt hat, die praktisch ausnutzbar wurde. Laut Wiz’ Berichthat auch Hyunwoo Kim (der ursprüngliche Melder von „Dirty Frag“) bestätigt, dass Fragnesia als unbeabsichtigter Nebeneffekt der „Dirty Frag“-Patches entstanden ist.

Das Gesamtbild ist beunruhigend: Sicherheitsteams müssen nun innerhalb von weniger als einer Woche dieselbe Angriffsfläche zweimal flicken, während die Entwickler von Exploits fast genauso schnell neue Versionen herausbringen, wie die Patches veröffentlicht werden.

Warum Fragnesia wichtig ist

„Fragnesia“ ist keine völlig eigenständige Fehlerklasse, die sich von „Dirty Frag“ unterscheidet. Es handelt sich um einen weiteren Ausnutzungsweg über dieselbe ESP/XFRM-Angriffsfläche, und der ursprüngliche Upstream-Fix für „Dirty Frag“ verhindert dies nicht vollständig.

Das technische Problem liegt in skb_try_coalesce(). Wenn diese Funktion paginierte Fragmente aus einem sk_buff in ein anderes einfügt, wird derzeit das SKBFL_SHARED_FRAG Marker, selbst wenn der resultierende Puffer noch Fragmente enthält, die externem Besitz unterliegen oder durch den Seiten-Cache gestützt werden. Dies verletzt die Invariante, auf die sich die ESP-Eingabeverarbeitung stützt – insbesondere die Funktion skb_has_shared_frag() , die entscheidet, ob ein nicht geklontes, nichtlineares skb skb_cow_data()überspringen kann. Wenn man das Copy-on-Write überspringt, erhält man eine In-Place-Entschlüsselung direkt in die gemeinsam genutzte Seite.

Mit anderen Worten: Die „Dirty Frag“-Korrektur (f4c50a4034e6) fügte Code hinzu, der davon ausgeht, dass der „shared-frag“-Marker korrekt ist. Der Marker ist jedoch nicht korrekt. Der vorgeschlagene „Fragnesia“-Patch enthält zwei Korrekturen: – einen für den „Dirty Frag“-Commit und einen für einen viel älteren Commit aus dem Jahr 2013 (cef401de7be8) – was darauf hindeutet, dass der zugrunde liegende Coalescing-Fehler schon seit Jahren besteht. Der „Dirty Frag“-Fix hat ihn lediglich auf eine nutzbare Weise ausnutzbar gemacht.

In der Praxis führt der Exploit zu genau dem Ergebnis, das den Sicherheitsverantwortlichen bereits letzte Woche Sorgen bereitete: die Änderung des Seiten-Caches privilegierter Binärdateien, ohne die zugrunde liegende Datei auf der Festplatte zu verändern.

Falls Sie bereits die „Dirty Frag“-Abwehrmaßnahme implementiert haben, die esp4, esp6und rxrpcverwendet, sind Sie bereits vor dem öffentlichen Fragnesia-PoC geschützt. Wenn Sie nur den ursprünglichen Upstream-Fix angewendet haben, ist dies nicht der Fall.

Diese Unterscheidung ist aus operativer Sicht von Bedeutung, da sie ein Muster bestätigt, das Verteidiger bei der Ausnutzung moderner Kernel-Schwachstellen zunehmend beobachten: Korrekturen für komplexe Fehler im Speichermanagement werden selbst zum Ziel von Forschungen zur schnellen Umgehung dieser Korrekturen.

So funktioniert der Exploit

Im Großen und Ganzen funktioniert der Exploit wie folgt:

1. Der Angreifer erstellt einen neuen Benutzer und einen neuen Netzwerk-Namespace mit unshare(CLONE_NEWUSER | CLONE_NEWNET) , um CAP_NET_ADMIN innerhalb des Sandbox-Namespace zu erlangen.
2. Eine Sicherheitsverbindung vom Typ „ESP-in-TCP“ im Transportmodus wird über NETLINK_XFRM unter Verwendung von AES-128-GCM mit einem bekannten Schlüssel eingerichtet.
3. Der Exploit erstellt eine 256 Einträge umfassende Keystream-Nachschlagetabelle unter Verwendung von AF_ALG und ordnet dabei jedem möglichen Byte-Wert einen entsprechenden Nonce zu.
4. Dateibasierte Seiten werden mithilfe von splice()in eine Warteschlange gestellt.
5. Der Socket wird in den Modus espintcp ULP-Modus, nachdem die Seiten bereits in die Warteschlange gestellt wurden.
6. Weil skb_try_coalesce() zuvor die Markierung für das gemeinsame Fragment entfernt hat, führt der Kernel die AES-GCM-Entschlüsselung direkt an Ort und Stelle auf den gemeinsam zwischengespeicherten Seiten durch.
7. Das ausgewählte Keystream-Byte wird mit der Zielseite XOR-verknüpft, wodurch ein kontrollierter Ein-Byte-Schreibvorgang erzeugt wird. Dies wird für jedes Byte wiederholt, bis die Nutzdaten geschrieben sind.

Der öffentliche PoC überschreibt die zwischengespeicherte Kopie von

/usr/bin/su mit einer kleinen positionsunabhängigen ELF-Nutzlast, die Folgendes ausführt:

setresuid(0,0,0);

execve("/bin/sh");

Der Exploit ist insofern bemerkenswert, als er nicht auf einem engen Zeitfenster beruht, das genau einmal erfolgreich sein muss. Der Angreifer wiederholt den Schreibvorgang so lange, bis die gewünschten Bytes erfolgreich gespeichert werden, wodurch der Vorgang weitaus deterministischer ist als viele frühere Exploits, die auf Race-Conditions im Kernel basierten.

Die geänderte zwischengespeicherte Seite kann bis zu ihrer Entfernung oder einem Neustart bestehen bleiben, was bedeutet, dass wiederholte Aufrufe der betroffenen Binärdatei weiterhin Root-Zugriff ermöglichen können, obwohl der Hashwert der Datei auf der Festplatte unverändert bleibt.

Wer ist am stärksten gefährdet?

Die Umgebungen mit dem höchsten Risiko sind Systeme, die Folgendes vereinen:

• Ausführung von nicht vertrauenswürdigem lokalem Code,
• nicht privilegierte Namespaces aktiviert,
• Workloads in mandantenfähigen Umgebungen,
• sowie aktive XFRM/ESP-Kernel-Unterstützung.

Daher ist es besonders wichtig, den folgenden Umgebungen Vorrang einzuräumen:

• Kubernetes-Worker-Knoten
• Gemeinsam genutzte CI/CD-Runner
• Shared-Hosting-Plattformen
• Bastion- und Jump-Hosts
• Entwickler-Workstations
• Mandantenfähige Container-Infrastruktur

Bei diesen Systemen ist eine Sicherheitslücke zur „lokalen“ Rechteausweitung selten noch wirklich lokal. Ein kompromittierter Container, ein bösartiger CI-Job, ein gestohlener SSH-Schlüssel oder eine RCE-Schwachstelle in einer Anwendung können allesamt als Sprungbrett für die vollständige Kompromittierung des Hosts dienen.

Patches für Fragnesia ohne Neustart mit KernelCare

Bei den oben genannten Systemen – Kubernetes-Knoten mit mehreren Mandanten, gemeinsam genutzte CI-Runner, Bastion-Hosts – stellt sich in der Praxis die Frage, wie schnell man einen Fix tatsächlich bereitstellen kann. Das rebootless Patching-Tool von TuxCare, KernelCare, lieferte innerhalb von 24 Stunden nach der Offenlegung von „Dirty Frag“ in der vergangenen Woche rebootless Patches für die EL8-Kernel-Familie aus, noch bevor die entsprechenden Errata der Hersteller erschienen. EL9, Ubuntu, Debian und Proxmox VE folgten im gleichen Release-Zyklus. Das ist der Maßstab dafür, wie „schnell“ in dieser Schweregradklasse aussieht.

Bei Fragnesia wird der Ablauf etwas chaotischer sein. Der Upstream-Fix befindet sich noch auf netdev und wartet auf Überprüfung, was bedeutet, dass der erste KernelCare-Patch auf Basis eines Kandidaten erstellt wird. Sollte die vom Maintainer zusammengeführte Version davon abweichen, ist mit einem Neuaufbau zu rechnen. Und da dieser Kandidaten-Patch ein „Fixes:“-Tag enthält, das auf einen Commit aus dem Jahr 2013 verweist, ist mit weiteren Überprüfungen von skb_try_coalesce() zu rechnen – der erste Patch, der ohne Neustart veröffentlicht wird, ist möglicherweise nicht der letzte für diese Angriffsfläche.

Genau dieser Rhythmus ist bei Patches ohne Neustart der Fall. Zwei Patches in fünf Tagen für dasselbe Subsystem, beide mit öffentlichen PoCs, bevor die Hersteller ihre Errata nachreichen konnten, und ein dritter, der wahrscheinlich noch kommt. Die Alternative – die im nächsten Abschnitt erläutert wird – besteht aus Modul-Blacklisting, Namespace-Einschränkungen und einem außerplanmäßigen rollierenden Neustart, sobald Ihre Distribution ein Kernel-Paket ausliefert. Kubernetes-Knoten, die zweimal in einer Woche leergeräumt wurden. CI-Runner, die mitten im Build-Zyklus neu gestartet wurden. Bastion-Failovers, die niemand geplant hatte.

Ein ehrlicher Hinweis: Einige Schwachstellenscanner melden die nicht gepatchte Version des Kernel-Pakets auch nach dem Live-Patching weiterhin als Schwachstelle, da die Erkennungslogik des Scanners dem aktuellen Status des laufenden Kernels hinterherhinkt. Der Kernel ist jedoch geschützt. Ihr Dashboard zeigt dies möglicherweise erst nach ein oder zwei Tagen an. Passen Sie die Erläuterung im Ticket entsprechend an.

Falls Sie KernelCare noch nicht nutzen und diese Woche Ihren Patch-Rhythmus unterbrochen haben, ist jetzt ein guter Zeitpunkt, sich das Angebot anzusehen. Bis Ende Juni gibt es für Neukunden einen Preisnachlass. KernelCare abonnieren → 

Milderung

Sofortige Abhilfemaßnahmen

Die gleiche Modul-Blacklist, die auch für „Dirty Frag“ verwendet wird, blockiert auch den öffentlichen „Fragnesia“-Exploit:

sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/fragnesia.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"

Wenn /etc/modprobe.d/dirtyfrag.conf bereits aus früheren Abhilfemaßnahmen vorhanden ist, können Sie es an Ort und Stelle belassen.

Betriebswarnung

Deaktivieren esp4 und esp6 beeinträchtigt die IPsec- und ESP-basierte VPN-Funktionalität, einschließlich Bereitstellungen mit strongSwan oder Libreswan. WireGuard-Bereitstellungen sind davon nicht betroffen.

rxrpc wird mit AFS-Clients in Verbindung gebracht und kann auf typischen Servern in der Regel bedenkenlos deaktiviert werden.

Überprüfen Sie die betrieblichen Abhängigkeiten, bevor Sie diese Maßnahmen flächendeckend umsetzen.

Benutzernamensräume für Benutzer ohne Sonderrechte einschränken

Ubuntu-Systeme sind gegen den öffentlichen PoC teilweise immun, da AppArmor standardmäßig die Namespaces nicht privilegierter Benutzer einschränkt. Der PoC selbst weist die Benutzer an, Folgendes zu deaktivieren:

kernel.apparmor_restrict_unprivileged_userns=0

vor der Nutzung.

Systeme der RHEL-Familie können einen vergleichbaren Schutz bieten durch:

echo "user.max_user_namespaces=0" > /etc/sysctl.d/fragnesia.conf

sysctl --system

Dies ist nur eine teilweise Abhilfe. Außerdem führt dies zu Fehlfunktionen bei Rootless-Containern, Flatpak, in Sandboxes ausgeführten Browsern und anderen namensraumabhängigen Tools.

Den mit Schadcode verseuchten Seiten-Cache leeren

Da der Exploit nur zwischengespeicherte Seiten verändert, sollten Systeme, bei denen der Verdacht auf eine Kompromittierung besteht, den Inhalt des Seiten-Caches nach der Abhilfe leeren:

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

Dadurch wird die unmittelbare Persistenz im Seitencache aufgehoben, es ist jedoch nicht gewährleistet, dass es dem Angreifer nicht gelingt, anschließend eine dauerhaftere Persistenz herzustellen. Jeder erfolgreiche Angriff sollte als vollständige Kompromittierung des Hosts behandelt werden.

Hersteller-Korrekturen anwenden

Installieren Sie vom Hersteller bereitgestellte Kernel-Updates oder geprüfte Live-Patches, sobald diese für Ihre Distribution verfügbar sind.

Zum Zeitpunkt der Veröffentlichung: William Bowlings Patch zur Weiterentwicklung des Kandidaten:

[PATCH net] net: skbuff: Beibehaltung des Markers für gemeinsam genutzte Fragmente beim Zusammenführen

befindet sich auf der netdev-Mailingliste und wartet auf Überprüfung. Der Patch ist klein – zwei Zeilen in skb_try_coalesce() , die den SKBFL_SHARED_FRAG beibehalten, wenn Fragmentdeskriptoren übertragen werden. Die Maintainer werden wahrscheinlich schnell eine Version davon einbinden, aber die Backports in die verschiedenen Distributionen dauern länger.

Das ist wichtig, da die Verantwortlichen dies möglicherweise als einen fortlaufenden Patch-Zyklus und nicht als einmalige Abhilfemaßnahme betrachten müssen. Die beiden Korrekturen: auf den Patches deuten darauf hin, dass umfassendere Überprüfungen im skb-Koaleszenzpfad erforderlich sind.

Leitfaden zur Erkennung

Herkömmliche Tools zur Überprüfung der Dateiintegrität sind für diese Art von Angriffen kaum geeignet:

• Die auf der Festplatte gespeicherten Hashwerte bleiben korrekt
• AIDE und Tripwire melden möglicherweise keine Änderungen
• Die unerwünschte Änderung verschwindet nach dem Leeren des Caches oder einem Neustart

Die Verhaltenserkennung ist weitaus vielversprechender.

Mögliche Anzeichen sind unter anderem:

• unshare(CLONE_NEWUSER | CLONE_NEWNET) von unerwarteten Prozessen
• NETLINK_XFRM Aktivität von Workloads, die nicht mit der VPN-Funktionalität in Zusammenhang stehen
• Ungewöhnlich stark AF_ALG Nutzung der Krypto-Schnittstelle, insbesondere in engen Schleifen
• splice() Operationen von regulären Dateien in TCP-Sockets, gefolgt von ULP-Änderungen am selben Socket

Keine dieser Maßnahmen ist für sich genommen bösartig, doch die Kombination ist verdächtig genug, um Regeln zur Erkennung zur Laufzeit unter Verwendung von eBPF-Tools, Falco, Tetragon oder Linux-EDR-Plattformen zu rechtfertigen.

Das übergeordnete Muster

Aktuelle Forschungsarbeiten zur Rechteausweitung unter Linux haben wiederholt Fehler im Zusammenhang mit der Beschädigung des Seiten-Caches, der Eigentumsregelung bei gemeinsam genutztem Speicher und der In-Place-Verarbeitung aufgezeigt, darunter:

• Dirty Pipe (2022)
• Kopieren fehlgeschlagen (2026)
• Dirty Frag (2026)
• Fragnesia (2026)

Drei davon tauchten innerhalb weniger Wochen auf.

Das gemeinsame Muster wird immer deutlicher: Hochoptimierte Kernel-Pfade, die die Verwaltung von gemeinsam genutztem Speicher, die Seitenverwaltung und die In-Place-Verarbeitung umfassen, führen weiterhin zu gefährlichen Schreiboperationen, wenn Annahmen in Randfällen nicht zutreffen.

splice(), SKB-Coalescing, ESP-Verarbeitung und Interaktionen mit dem Seiten-Cache sind allesamt leistungsorientierte Subsysteme. Angreifer beweisen zunehmend, dass diese Optimierungen zu zuverlässigen Wegen für die Ausweitung von Berechtigungen werden können, wenn die Semantik der Eigentumsrechte zusammenbricht.

Fragnesia fällt auch dadurch auf, wie schnell es auftauchte, nachdem die ursprünglichen „Dirty Frag“-Patches veröffentlicht worden waren. V12 Security führt einen Teil des Entdeckungsprozesses auf agentenbasierte, KI-gestützte Sicherheitstools zurück, und ganz gleich, wie viel Gewicht man dieser Behauptung beimisst – die Geschwindigkeit, mit der neue Exploit-Varianten auftauchen, nimmt zu. Die Tatsache, dass der vorgeschlagene Patch eine Fixes: -Tag, das auf einen Commit aus dem Jahr 2013 verweist, deutet ebenfalls darauf hin, dass diese Fehlerklasse noch nicht ausgeschöpft ist – wahrscheinlich warten im selben Codepfad noch weitere Invariantenverletzungen darauf, entdeckt zu werden.

Verteidiger sollten davon ausgehen, dass diese Insektenklasse ihre Entwicklung noch nicht abgeschlossen hat.

Zusammenfassung

Artikel Name

Fragnesia (CVE-2026-46300): Neue Linux-LPE, die den „Dirty Frag“-Patch umgeht

Beschreibung

Fragnesia (CVE-2026-46300) ist eine neue LPE im Linux-Kernel, die die „Dirty Frag“-Familie (CVE-2026-43284, CVE-2026-43500) erweitert.

Autor

Tim Walker

Name des Herausgebers

TuxCare

Logo des Herausgebers