Dirty Frag – eine neue, bislang nicht behobene Schwachstelle zur lokalen Privilegieneskalation im Linux-Kernel, die es jedem lokalen Benutzer ermöglicht, Root-Rechte auf den meisten populären Distributionen zu erlangen (Ubuntu 24.04.4, RHEL 10.1, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10, Fedora 44 u.a.), wobei der standardmäßige temporäre Schutz vor Copy Fail (CVE-2026-31431) nicht greift: Es wurde ein funktionierender Proof-of-Concept veröffentlicht, die Ausnutzung erfolgt mit einem einzigen Befehl, und bis Patches erscheinen, bleibt als einzige praktische Maßnahme das Blockieren der Module esp4, esp6 und rxrpc.

Technische Details zu Dirty Frag

Forscher Hyunwoo Kim beschreibt Dirty Frag als Weiterentwicklung derselben Klasse von logischen Kernel-Fehlern, zu der auch die Schwachstellen Dirty Pipe und Copy Fail (CVE-2026-31431, CVSS 7.8) gehören. Das zentrale Merkmal dieser Klasse ist ein deterministischer Logikfehler ohne Race Condition:

• es ist keine Race Condition oder exaktes Timing nötig;
• bei einem fehlgeschlagenen Exploit-Versuch stürzt der Kernel nicht ab (kein Panic);
• die Wahrscheinlichkeit einer erfolgreichen Privilegieneskalation liegt in einer passenden Konfiguration nahe bei 100 %.

Dirty Frag basiert auf der Kombination zweier unterschiedlicher Fehler bei Schreibzugriffen in den Page Cache des Kernels: xfrm-ESP Page-Cache Write und RxRPC Page-Cache Write. Beide Fehler ermöglichen eine fehlerhafte Modifikation von Daten im Page Cache, die weiterhin unter der Kontrolle eines nicht privilegierten Prozesses stehen. Das ist ein klassisches Szenario zur Ausnutzung einer Schwachstelle des Typs Exploit for Privilege Escalation (T1068) nach MITRE ATT&CK.

xfrm-ESP Page-Cache Write: 4-Byte-Schreibprimitiv über IPSec

Die erste Komponente ist eine Schwachstelle in der IPSec-Subsystem (xfrm), die der Forscher als xfrm-ESP Page-Cache Write bezeichnet. Der Fehler:

• entstand nach einem Commit im Januar 2017;
• steht im Zusammenhang mit derselben Änderung, die zum Pufferüberlauf CVE-2022-27666 (CVSS 7.8) führte, der im NVD-Eintrag zu CVE-2022-27666 beschrieben ist;
• verschafft dem Angreifer ein 4-Byte-Schreibprimitiv in den Page Cache des Kernels, ähnlich mächtig wie das, welches bei Copy Fail verwendet wurde.

Dieser Teil des Exploits stützt sich auf das Zusammenspiel von ESP und Page Cache: Bei der Verarbeitung von IPSec-Traffic (über die XFRM user netlink-Schnittstelle) führt der Kernel Entschlüsselungsoperationen „in-place“ auf Seiten aus, die von externen Objekten gestützt sein können (z.B. Pipe-Seiten, die über splice() oder sendfile() angehängt wurden). Dabei ist ein Schreibzugriff auf Daten möglich, auf die ein nicht privilegierter Prozess weiterhin eine Referenz hält.

Eine kritische Einschränkung: Für die Ausnutzung der xfrm-ESP-Variante ist die Möglichkeit erforderlich, User-Namespaces zu erstellen. Unter Ubuntu wird dies standardmäßig durch AppArmor-Profile blockiert, sodass dieser Exploit-Pfad in einer solchen Konfiguration nicht verfügbar ist.

RxRPC Page-Cache Write: Umgehung des Verbots zur Namespace-Erstellung

Die zweite Komponente ist RxRPC Page-Cache Write. Sie kam später in den Kernel, nach einem Commit vom Juni 2023, und wiederholt dasselbe fehlerhafte Muster im Entschlüsselungspfad, jedoch:

• erfordert nicht das Recht, User-Namespaces zu erstellen;
• verwendet das Modul rxrpc.ko, das in vielen Distributionen (z.B. RHEL 10.1) in der Standardauslieferung fehlt, in Ubuntu jedoch standardmäßig geladen wird.

Aus technischer Sicht ist der Fehler analog: Das RxRPC-Subsystem führt, ebenso wie esp4/esp6, Entschlüsselung „in-place“ auf Seiten aus, die nicht vollständig exklusiv dem Kernel vorbehalten sind. Dadurch können entschlüsselte Daten oder Kernelstrukturen, die sich auf diesen Seiten befinden, durch Code eines nicht privilegierten Prozesses verfälscht werden.

Exploit-Kette: Gegenseitige Abdeckung der „blinden Flecken“

Der zentrale technische Kniff von Dirty Frag ist die Kombination beider Schwachstellen so, dass jede die Einschränkungen der anderen ausgleicht:

• in Umgebungen, in denen die Erstellung von User-Namespaces erlaubt ist, das Modul rxrpc.ko jedoch nicht verfügbar ist oder nicht geladen wird, kommt die xfrm-ESP-Variante zum Einsatz;
• in Umgebungen wie Ubuntu, wo AppArmor die Erstellung von User-Namespaces blockiert, rxrpc.ko aber standardmäßig aktiviert ist, wird die RxRPC-Variante ausgenutzt.

Damit existiert für die meisten weit verbreiteten Distributionen mindestens ein funktionierender Exploit-Pfad, in manchen Konfigurationen sogar beide. Der Forscher betont, dass Dirty Frag unabhängig davon erfolgreich ausgenutzt werden kann, ob das Modul algif_aead aktiv ist oder nicht. Das heißt, selbst Systeme, auf denen Copy Fail vermeintlich durch Blockierung von algif_aead „geschlossen“ wurde, bleiben gegenüber der neuen Technik verwundbar.

Bedrohungskontext und Zusammenhang mit Copy Fail

Copy Fail (CVE-2026-31431), die vorangegangene Schwachstelle derselben Klasse, wird nach Angaben des Forschers bereits aktiv in realen Angriffen ausgenutzt. Das ist ein wichtiger Indikator: Sobald für diese Kategorie logischer Fehler in Subsystemen zur Verarbeitung von Netzdaten ein öffentlicher Exploit vorliegt, bauen Angreifer ihn schnell in ihre Angriffsketten ein – von Web-Shells bis hin zu Container-Breakouts.

Dirty Frag hat mehrere unangenehme Eigenschaften von Copy Fail und Dirty Pipe geerbt:

• lokaler Angriffsvektor, aber mit sehr niedriger Einstiegsschwelle (fertiger PoC und Ausführung mit einem einzigen Befehl);
• Universalität – dieselben Schreibprimitive können auf unterschiedliche Ziele im Speicher angewendet werden (Austausch von Binaries, Modifikation von /etc/passwd oder /etc/shadow, Einschleusung in Sicherheitsprozesse usw.);
• Fehlen auffälliger Kernel-Fehler bei fehlgeschlagener Ausnutzung, was die Erkennung über Ausfallereignisse erschwert.

Im Unterschied zu Copy Fail umgeht die neue Technik den wichtigsten bekannten temporären Schutz – die Blockierung des Moduls algif_aead. Damit sind alle aktuellen „Schnellfixes“ für Copy Fail unvollständig: Infrastrukturen, die sich ausschließlich auf eine Blocklist für algif_aead verlassen, wiegen sich in falscher Sicherheit, während das volle Risiko einer lokalen Root-Übernahme bestehen bleibt.

Auswirkungsanalyse für Organisationen

Am stärksten gefährdet sind Umgebungen, in denen ein potenzieller Angreifer irgendeine Form von lokalem Zugriff erlangen kann – sei es interaktiv oder über die Ausnutzung anderer Anwendungsschwachstellen:

• Anbieter von Cloud- und Hosting-Services mit Multiuser-Linux-Servern;
• unternehmensweite Applikationsserver (Web, Datenbanken, CI/CD), bei denen die Kompromittierung eines Dienstes zu einem lokalen Zugriff mit niedrigen Rechten führt;
• virtuelle Desktops und Terminalserver auf Linux-Basis mit vielen nicht privilegierten Konten;
• Entwicklungs- und Testumgebungen, in denen häufig zusätzliche Kernel-Subsysteme aktiviert sind und weniger strenge Sicherheitsrichtlinien gelten.

Mögliche Konsequenzen bei Untätigkeit:

• sofortige Privilegieneskalation auf Root nach jedem lokalen Footprint (RCE in einer Web-Anwendung, kompromittiertes Benutzerkonto, verwundbarer Container);
• dauerhafte Persistenz im System durch Modifikation von System-Binaries, Bootloadern, Kernel-Modulen oder Konfigurationen;
• Abschaltung oder Manipulation von Schutzmechanismen (EDR-Agenten, Audit-Logs);
• Verstöße gegen Compliance-Anforderungen, bei denen die Kontrolle administrativer Zugriffe und die Integrität von Systemen zentrale Auditelemente sind.

Besonders gefährlich ist, dass nach Aussage des Forschers bereits ein voll funktionsfähiger PoC verfügbar ist, der die Eskalation „mit einem einzigen Kommando“ durchführt. Dadurch verkürzt sich die Zeitspanne zwischen dem Bekanntwerden der Schwachstelle und ihrer breiten Aufnahme in Exploit-Kits, einschließlich automatisierter Werkzeuge, drastisch.

Praktische Schutzempfehlungen

1. Sofortige temporäre Maßnahmen

Bis zur Veröffentlichung offizieller Patches für den Linux-Kernel wird empfohlen:

• die Ladung der Module esp4, esp6 und rxrpc zu blockieren:
  • fügen Sie in Dateien unter /etc/modprobe.d/ folgende Zeilen ein:
    • blacklist esp4
    • blacklist esp6
    • blacklist rxrpc
  • laden Sie nach Möglichkeit bereits geladene Module aus: rmmod esp4 esp6 rxrpc (unter Berücksichtigung des Risikos von Serviceunterbrechungen).
• bewerten Sie bewusst die Auswirkungen auf Ihre Infrastruktur: Das Blockieren von esp4/esp6 betrifft IPSec-Tunnel, und das Deaktivieren von rxrpc betrifft Dienste, die dieses Protokoll nutzen.

Dies korreliert direkt mit der Empfehlung des Herstellers AlmaLinux, der den Defekt im Pfad „ESP-in-UDP MSG_SPLICE_PAGES no-COW fast path“ und seine Erreichbarkeit über die XFRM user netlink-Schnittstelle beschreibt.

2. Prüfung der Verwundbarkeit

Grundschritte zur Risikobewertung:

• Identifizieren Sie Distributionen und Versionen, die im Risikobereich liegen:
  • bestätigt sind u.a.: Ubuntu 24.04.4, RHEL 10.1, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10, Fedora 44;
  • bei vergleichbaren Kernel-Versionen können auch andere Distributionen verwundbar sein.
• Prüfen Sie, ob die entsprechenden Module geladen sind:
  • lsmod | egrep 'esp4|esp6|rxrpc'
  • bei Bedarf – modinfo esp4, modinfo rxrpc zur Bestätigung, dass die Module im System vorhanden sind.
• Überprüfen Sie die Richtlinien zur Erstellung von User-Namespaces:
  • auf Ubuntu-Systemen – Kontrolle der AppArmor-Profile;
  • auf Servern anderer Distributionen – soweit möglich die Erstellung von User-Namespaces für nicht privilegierte Benutzer einschränken.

3. Verstärkung von Monitoring und Incident Response

Angesichts eines verfügbaren PoC ist es sinnvoll:

• unerwartete Ladevorgänge der Module esp4, esp6 und rxrpc zu überwachen (über auditd, systemd-journald, Kernel-Monitoring-Werkzeuge);
• den Start von Werkzeugen zu kontrollieren, die splice() und sendfile() in für das System untypischen Kombinationen nutzen, insbesondere durch nicht privilegierte Accounts;
• die Reaktion auf jegliche Anzeichen lokaler Kompromittierung zu verstärken – von Hinweisen auf Web-Shells bis zu verdächtigen Binaries im Home-Verzeichnis eines Benutzers: Mit Dirty Frag sollte jeder lokale Zugriff als potenzielle Root-Erlangung betrachtet werden.

4. Vorbereitung auf die Installation von Patches

Da die Kernel-Entwickler am 30. April 2026 über die Schwachstelle informiert wurden, ist in naher Zukunft mit Updates in den von den Distributionen unterstützten Zweigen zu rechnen. Es wird empfohlen, im Voraus:

• ein außerplanmäßiges Kernel-Update mit möglichen Neustarts kritischer Systeme einzuplanen;
• eine Testumgebung vorzubereiten, um die Auswirkungen der Patches auf kritische Dienste zu prüfen (insbesondere solche, die IPSec und RxRPC nutzen);
• das Erscheinen eines Eintrags für Copy Fail CVE-2026-31431 und verwandte Schwachstellen derselben Klasse in der NVD sowie die Empfehlungen der Distributionshersteller zu verfolgen.

Das wichtigste Fazit: Dirty Frag eröffnet einen universellen Weg zu Root-Rechten für jeden lokalen Angreifer auf den meisten modernen Linux-Distributionen, und die bislang eingesetzten temporären Maßnahmen gegen Copy Fail bieten keinen ausreichenden Schutz mehr; priorisieren Sie daher die sofortige Blockierung der Module esp4, esp6 und rxrpc überall dort, wo dies mit den Geschäftsprozessen vereinbar ist, und bereiten Sie Ihre Infrastruktur auf eine schnelle Einführung aktualisierter Kernel unmittelbar nach Veröffentlichung der offiziellen Patches vor.