DIRTY FRAG: WARUM JEDES LINUX-SYSTEM GERADE VERWUNDBAR IST.

Am 7. Mai 2026 wurde eine kritische Sicherheitslücke im Linux-Kernel veröffentlicht, die unter dem Namen Dirty Frag bekannt wird. Sie ermöglicht es einem lokalen Angreifer, ohne Race Condition und mit sehr hoher Zuverlässigkeit vollständige Root-Rechte auf dem betroffenen System zu erlangen – auf nahezu allen gängigen Linux-Distributionen. Ein Patch existiert für den Großteil der Systeme aktuell nicht.

Was ist Dirty Frag?

Dirty Frag gehört zur selben Klasse von Schwachstellen wie die bekannten Linux-Lücken Dirty Pipe (CVE-2022-0847) und Copy Fail (CVE-2026-31431). Das Grundprinzip: Über den Systemaufruf splice() kann ein Angreifer eine Seite des Seitencaches (Page Cache) – also eine im Arbeitsspeicher gehaltene Kopie einer Datei wie /etc/passwd oder /usr/bin/su – in einen Netzwerk-Puffer einschleusen. Anschließend führen bestimmte Kernel-Pfade eine kryptografische Operation direkt auf dieser Seite durch, anstatt zuerst eine private Kopie anzulegen.

Das Ergebnis: Der Angreifer kann den Inhalt von Dateien im Arbeitsspeicher modifizieren, auf die er nur Leserechte hat – dauerhaft, bis zum nächsten Neustart oder einem manuellen Cache-Flush.

Zur Einordnung: Dirty Pipe (2022) war eine ähnliche Klasse, betraf aber Pipe-Buffer. Dirty Frag erweitert das Prinzip auf sk_buff-Fragmente – also Netzwerkpuffer. Der entscheidende Unterschied: Dirty Frag braucht keine Race Condition und hat eine deutlich höhere Erfolgsrate.

Die zwei Angriffsvektoren im Detail

Dirty Frag kombiniert zwei unabhängige Schwachstellen, die sich gegenseitig ergänzen, um Lücken in verschiedenen Systemkonfigurationen auszunutzen.

1. xfrm-ESP Page-Cache Write – der universelle Angriff

Diese Variante nutzt einen Fehler im IPsec-Stack (ESP-Protokoll). Beim Empfang eines ESP-Pakets sollte der Kernel vor der kryptografischen Verarbeitung eine private Kopie des Netzwerk-Puffers anlegen – das tut er aber in einem bestimmten Codepfad nicht. Stattdessen läuft die In-Place-Entschlüsselung direkt auf der Seite des Seitencaches.

Was der Angreifer kontrolliert: Durch den ESN-Parameter (Extended Sequence Number) im XFRM-SA kann er exakt 4 Bytes an einem selbst gewählten Datei-Offset schreiben – mit einem selbst gewählten Wert. Das ergibt ein deterministisches, zuverlässiges Schreib-Primitiv.

Einschränkung: Diese Variante benötigt das Recht, einen User Namespace zu erstellen (unshare). Auf Ubuntu kann das durch AppArmor-Policies blockiert sein.

2. RxRPC Page-Cache Write – der Angriff ohne Namespace-Rechte

Diese Variante nutzt den RxRPC-Stack (Andrew File System Protokoll). Dieselbe Grundstruktur: In-Place-Krypto auf einer über splice() eingeschleusten Page-Cache-Seite. Hier werden 8 Bytes geschrieben, deren Wert durch eine fcrypt-Operation mit einem vom Angreifer kontrollierten Schlüssel bestimmt wird.

Der Angreifer muss den richtigen Schlüssel per Brute-Force in User-Space berechnen – was bei wenigen zu kontrollierenden Bytes (Ziel: /etc/passwd) in unter einer Sekunde möglich ist.

Vorteil: Kein Namespace-Recht erforderlich. Einschränkung: Das rxrpc.ko-Modul muss verfügbar sein, was auf Ubuntu standardmäßig der Fall ist.

Das Zusammenspiel

• Auf Systemen ohne AppArmor-Namespace-Sperre → ESP-Variante erzielt Root über /usr/bin/su
• Auf Ubuntu mit AppArmor-Sperre, aber rxrpc.ko → RxRPC-Variante erzielt Root über leeres /etc/passwd-Passwort
• Ergebnis: Eine einzige Exploit-Binary funktioniert auf nahezu allen Distributionen

Betroffene Systeme

Die ESP-Schwachstelle ist in Kernel-Commits seit Januar 2017 vorhanden, die RxRPC-Schwachstelle seit Juni 2023. Getestet und bestätigt auf:

• Ubuntu 24.04.4 (Kernel 6.17.0-23-generic)
• RHEL 10.1 (Kernel 6.12.0-124.49.1.el10_1.x86_64)
• CentOS Stream 10, AlmaLinux 10, Fedora 44
• openSUSE Tumbleweed (Kernel 7.0.2-1-default)
• Debian 13 (Kernel 6.12.85-1)

Nicht betroffen sind Systeme, auf denen die betroffenen Kernel-Module esp4, esp6 und rxrpc aktiv deaktiviert wurden. Das ist auf allen Systemen, die kein IPsec nutzen, stärkstens empfohlen.

Patch-Status

Die ESP-Schwachstelle wurde am 7. Mai 2026 in den netdev-Tree gemergt. Ein Distribution-Backport steht für die meisten Systeme noch aus. Die RxRPC-Schwachstelle hat noch keinen upstream Patch.

Hinweis: Das Embargo wurde am 7. Mai 2026 durch eine unbekannte Drittpartei vorzeitig gebrochen. Der vollständige Exploit-Code ist öffentlich verfügbar. Die Bedrohungslage ist unmittelbar, nicht theoretisch.

Sofortmaßnahmen für Administratoren

Bis Patches verfügbar sind, empfehlen wir die folgenden Mitigationsschritte:

Schritt 1: Module deaktivieren (empfohlen)

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

Als Administrator ausgeführt, deaktivieren diese Befehle die betroffenen Kernel-Module dauerhaft. Achtung: Wenn esp4/esp6 für aktive IPsec-VPN-Verbindungen benötigt werden, entfallen diese dadurch.

Schritt 2: Page Cache leeren

echo 3 > /proc/sys/vm/drop_caches

Falls ein Exploit bereits ausgeführt wurde, löscht dieser Befehl den kontaminierten Page Cache. Ein Systemneustart hat denselben Effekt.

Schritt 3: Kernel-Updates priorisieren

Überwachen Sie die Patch-Releases Ihrer Distribution aktiv. Sobald ein Backport verfügbar ist, sollte das Kernel-Update mit höchster Priorität ausgerollt werden.

Schritt 4: Monitoring intensivieren

Suchen Sie in Ihren Logs nach auffälligen splice()-Syscalls in Kombination mit xfrm- oder rxrpc-bezogenen Netzwerkaktivitäten.

Ein Indikator einer Kompromittierung sind folgende Einträge im Kernel-Log:

alg: No test for authencesn(hmac(sha256),cbc(aes)) (authencesn(hmac(sha256-ssse3),cbc-aes-aesni))
alg: No test for echainiv(authencesn(hmac(sha256),cbc(aes))) (echainiv(authencesn(hmac(sha256-ssse3),cbc-aes-aesni)))
process 'su' launched '/bin/sh' with NULL argv: empty string added

Diese Log-Einträge zeigen, dass spezielle Kombinationen von Verschlüsselungsfunktionen ohne Test-Suite aufgerufen wurden, sowie die Ausführung von su ohne Argumente – beides charakteristisch für den Proof-of-Concept-Exploit.

Wie Trufflepig helfen kann

Wir unterstützen Sie bei der unmittelbaren Einschätzung Ihrer Exposition und der Umsetzung der Mitigationsschritte.

Betreiben Sie Linux-Server und sind unsicher, ob Sie betroffen sind? Kontaktieren Sie uns direkt.

Sofort-Hilfe bei Bedarf: +49 157 92500100

Kontakt Deutschland Trufflepig IT-Forensics GmbH Hopfenstraße 28 85283 Wolnzach +49 8441 4799976 kontakt@trufflepig-forensics.de

Kontakt Schweiz Trufflepig IT-Forensics AG Avenue Beauregard 1 1700 Freiburg +41 26 588 01 82 kontakt@trufflepig-forensics.ch