DirtyClone-Lücke im Linux-Kernel: Angriff auf Page Cache und Root-Eskalation

Die Schwachstelle CVE-2026-43503 (CVSS 8.8), die den Namen DirtyClone erhalten hat, ermöglicht es einem lokalen Benutzer, den Inhalt von Dateien im Page Cache des Linux-Kernels über das Klonen von Netzwerkpaketen zu manipulieren und Root-Privilegien zu erlangen. Am 25. Juni veröffentlichte JFrog Security Research einen funktionsfähigen Exploit mit einer Schritt-für-Schritt-Beschreibung des Angriffs. Der Patch wurde am 21. Mai in den Mainline-Kernel aufgenommen; Ubuntu, Debian, SUSE und Red Hat haben bereits Updates veröffentlicht oder verfolgen das entsprechende Fix. Am stärksten gefährdet sind Mehrbenutzer-Server, Container-Hosts, CI-Runner und Kubernetes-Cluster, in denen nicht privilegierte Benutzer Namespaces anlegen können.

Mechanismus der Schwachstelle

Nach Angaben der JFrog-Forscher liegt die Hauptursache von DirtyClone im Verlust eines Flags, das den Speicher eines Netzwerkpakets als gemeinsam mit einer Datei auf dem Datenträger genutzten Speicher markiert. Wenn der Kernel ein Netzwerkpaket intern kopiert, setzen die Hilfsfunktionen __pskb_copy_fclone() und skb_shift() dieses Sicherheits-Flag zurück. Ein verlorenes Bit reicht aus, um eine Zero-Copy-Optimierung in ein Schreib-Primitive zu verwandeln.

Die Exploit-Kette gestaltet sich den Berichten zufolge wie folgt:

1. Der Angreifer lädt eine privilegierte Binärdatei (zum Beispiel /usr/bin/su) in den Speicher und verknüpft die entsprechenden Speicherseiten mit einem Netzwerkpaket.
2. Der Kernel klont dieses Paket und verliert dabei das Flag für gemeinsam genutzte Fragmente.
3. Das geklonte Paket durchläuft einen vom Angreifer kontrollierten IPsec-Tunnel.
4. In der Entschlüsselungsphase wird der Inhalt mit beliebigen Bytes überschrieben – Authentifizierungsprüfungen in der Binärdatei werden durch den Code des Angreifers ersetzt.
5. Beim nächsten Start von su durch einen beliebigen Benutzer des Systems werden Root-Privilegien übertragen.

Ein kritisches Merkmal des Angriffs: Die Datei auf dem Datenträger bleibt unverändert. Die Modifikation existiert nur im Page Cache des Kernels, sodass File-Integrity-Monitoring-Systeme die Manipulation nicht erkennen und ein Neustart die ursprüngliche Binärdatei wiederherstellt. Zu dem Zeitpunkt, zu dem eine mögliche Überprüfung stattfindet, verfügt der Angreifer bereits über Root-Rechte.

Voraussetzungen für die Ausnutzung

Für die Einrichtung eines IPsec-Tunnels auf dem Loopback-Interface ist die Privilegie CAP_NET_ADMIN erforderlich. Nach Angaben der Forscher sind auf Debian und Fedora unprivilegierte User Namespaces standardmäßig aktiviert, was es einem lokalen Benutzer ermöglicht, diese Privilegie innerhalb eines neuen Namespaces zu erhalten. Da der Page Cache auf Host-Ebene gemeinsam genutzt wird, betreffen Modifikationen, die innerhalb eines Namespaces vorgenommen werden, alle Prozesse auf der Maschine.

Ubuntu 24.04 und spätere Versionen beschränken die Erstellung von Namespaces über AppArmor, was nach Angaben von JFrog den Standard-Exploit-Pfad blockiert. Dennoch bleibt die Schwachstelle im Kernel bestehen, und alternative Angriffsvektoren sind nicht ausgeschlossen.

JFrog hat die Funktionsfähigkeit des Exploits auf Debian-, Ubuntu- und Fedora-Systemen mit Standardkonfiguration der Namespaces bestätigt.

Vierte Schwachstelle der Serie

DirtyClone ist die vierte Privilegieneskalations-Schwachstelle mit demselben Ausfallmechanismus in den letzten zwei Monaten. Alle stehen im Zusammenhang mit Situationen, in denen Dateispeicher wie Paketdaten behandelt wird und eine Netzwerkoperation an eine Stelle schreibt, an der sie eigentlich kopieren sollte:

• Copy Fail (CVE-2026-31431) – Ende April, ein 4-Byte-Schreibvorgang in den Page Cache über das Modul algif_aead.
• DirtyFrag (CVE-2026-43284, CVE-2026-43500) – 7. Mai, vollständiger Schreib-Primitive über IPsec ESP und RxRPC.
• Fragnesia (CVE-2026-46300) – 13. Mai, Umgehung des DirtyFrag-Patches durch einen Fehler beim Zurücksetzen eines Flags in skb_try_coalesce().

Jedes Fix schloss einen bestimmten Pfad im Code und ließ andere offen. Das grundlegende Problem hat einen vertraglichen Charakter: Jeder Codepfad, der skb-Fragmente verschiebt, ist verpflichtet, das Shared-Fragment-Bit beizubehalten. Der Zero-Copy-Mechanismus im Netzwerk-Stack des Kernels erlaubt es, dass Dateispeicher als Paketdaten fungiert, und ein einziges verlorenes Flag an irgendeiner Stelle der Kette verwandelt eine Performance-Optimierung in eine Schwachstelle.

Der Forscher Hyunwoo Kim, der das ursprüngliche DirtyFrag entdeckt hat, stellte am 16. Mai einen erweiterten Patch vor, der mehrere verbleibende Hilfsfunktionen zur Fragmentübertragung abdeckt. Das zusammengeführte Fix wurde am 21. Mai übernommen (Commit 48f6a5356a33), die Kennung CVE-2026-43503 wurde am 23. Mai vergeben, der Fix ist in Linux v7.1-rc5 enthalten.

Bewertung der Auswirkungen

Am stärksten gefährdet sind Umgebungen mit Mehrbenutzerzugriff:

• Mehrbenutzer-Server mit gemeinsamem SSH-Zugang
• Container-Hosts und Kubernetes-Cluster, in denen Benutzer Namespaces anlegen können
• CI/CD-Runner, die Code aus nicht vertrauenswürdigen Repositories ausführen
• Beliebige Systeme unter Debian oder Fedora mit Standardkonfiguration der Namespaces

Das Fehlen von Spuren in Audit-Logs und die Unsichtbarkeit für File-Integrity-Monitoring-Lösungen machen diese Schwachstelle besonders gefährlich für Infrastrukturen, die sich auf diese Erkennungsmechanismen stützen.

Empfehlungen zum Schutz

Maßnahme mit höchster Priorität ist die Installation des Kernel-Updates Ihres Distributors. Das Fix ist in den Mainline-Kernel (v7.1-rc5) eingeflossen und in stabile sowie LTS-Zweige zurückportiert worden. Security Advisories wurden von Ubuntu, Debian und SUSE veröffentlicht.

Falls ein sofortiges Update nicht möglich ist, stehen zwei temporäre Workarounds zur Verfügung:

• Einschränkung unprivilegierter Namespaces: unter Debian und Ubuntu den Wert kernel.unprivileged_userns_clone=0 setzen. Andere Distributionen verwenden andere Mechanismen.
• Blockieren von Kernel-Modulen: die Module esp4, esp6 und rxrpc auf die Blacklist setzen. Dies unterbricht IPsec und AFS und ist nur anwendbar, wenn diese Komponenten als Module geladen und nicht fest in den Kernel einkompiliert sind.

Beide Workarounds sind temporäre Maßnahmen, die die Schwachstelle nicht beseitigen.

Die DirtyFrag-Serie macht ein systemisches Problem im Netzwerk-Stack des Linux-Kernels deutlich: Jede Funktion, die Fragment-Deskriptoren verschiebt, ohne das Shared-Fragment-Flag zu erhalten, ist potenziell eine neue Schwachstelle. Organisationen, die Mehrbenutzer-Linux-Systeme betreiben, sollten nicht nur den aktuellen Patch einspielen, sondern auch die Überwachung von Kernel-Updates, die die Behandlung von skb_shinfo()->flags bei der Fragmentübertragung betreffen, in ihren regulären Vulnerability-Management-Prozess aufnehmen.