Dirty Frag (CVE-2026-43284): Linux-Kernel-LPE — Module blacklisten, IPsec abwägen, Customer-Stacks schützen

Eine neu offengelegte Linux-Kernel-Schwachstelle namens Dirty Frag (CVE-2026-43284) erlaubt unprivilegierten Nutzern in kurzer Zeit vollen Root-Zugriff auf das System — eine universelle Local Privilege Escalation. Betroffen sind alle Linux-Versionen seit 2017, einschließlich Kernel 7.0.4. Bis zum Patch ist die empfohlene Mitigation, drei verwundbare Kernel-Module (esp4, esp6, rxrpc) per /etc/modprobe.d/dirtyfrag.conf zu blockieren und falls bereits geladen mit rmmod zu entladen — AWS empfiehlt zusätzlich ipcomp4 und ipcomp6 als Defense-in-Depth. Trade-off: IPsec und die kAFS-Variante des AFS-Filesystems brechen, OpenAFS bleibt unberührt. Für Customer-Stacks im Mittelstand bedeutet das eine Wochen-Aufgabe: Inventur der Linux-Hosts, Prüfung welche IPsec/kAFS einsetzen, Mitigation in der nicht-kritischen Welle, Abschluss mit Kernel-Patch sobald distributionsseitig verfügbar. Achter Trust-/CVE-Post in unserem Cluster, in direkter Linie zu Copy Fail (Mai 2026).

Was die Schwachstelle ist

Dirty Frag (CVE-2026-43284) wird seit 8. Mai 2026 offiziell getrackt (CVE-Nummer zuerst von AlmaLinux veröffentlicht). Die UMich-Information-Assurance-Meldung vom 7. Mai 2026 beschreibt sie als universelle Linux-LPE: Ein lokaler Nutzer ohne weitergehende Rechte kann in kurzer Zeit Root erlangen. Der Public-Proof-of-Concept liegt auf github.com/V4bel/dirtyfrag.

Betroffen sind nach UMich-Angaben alle Linux-Versionen, die seit 2017 veröffentlicht wurden, einschließlich Kernel 7.0.4. Das ist eine ungewöhnlich breite Reichweite — vergleichbar mit Copy Fail, das wir Anfang Mai im Cluster diskutiert haben (CVE-2026-31431). Vergleichbar nicht im technischen Detail, aber in der Konsequenz: jede Linux-Maschine, die nicht mitigiert oder gepatcht ist, ist heute ein Ein-Schritt-Ziel für lokale Eskalation.

Die oss-security-Disclosure vom 7. Mai 2026 liefert die technische Anatomie: Dirty Frag ist eine Verkettung von zwei separaten Page-Cache-Write-Schwachstellen — einmal in xfrm-ESP (IPsec-Fast-Path mit MSG_SPLICE_PAGES no-COW) und einmal in RxRPC (kAFS-Transport-Schicht). Erreichbar wird die Verkettung über das XFRM-User-Netlink-Interface, das die zugehörigen Kernel-Module bei Bedarf automatisch nachlädt. Das ist der Grund, warum die Mitigation genau diese drei Module (esp4, esp6, rxrpc) trifft — sie sind die Eintrittstür zur Verkettung, auch auf Hosts, die selbst weder IPsec noch kAFS aktiv einsetzen.

Bestätigt betroffen laut oss-security und nachfolgenden Distributions-Meldungen: Ubuntu 24.04.4, RHEL 10.1, CentOS Stream 10, AlmaLinux 10, Fedora 44, openSUSE Tumbleweed — also alle Mainstream-Distributionen mit aktuellen Kerneln bis 7.0.x. Für den DACH-Mittelstand-Stack heißt das: praktisch jede Linux-Box im Default-Setup betroffen, unabhängig von der Distributions-Wahl.

Die Disclosure verlief unkoordiniert: das linux-distros-Embargo war für den 12. Mai 2026 angesetzt, eine Drittpartei hat am 7. Mai vorzeitig den ESP-Teil veröffentlicht, was den Forscher zur sofortigen Vollveröffentlichung gezwungen hat. Das ist der Grund, warum Patches bei Public-Disclosure noch nicht fertig waren und CVE-IDs ausstanden — und warum die Modul-Blacklist-Mitigation in den ersten Tagen die einzige verfügbare Verteidigung ist.

Patch-Status zum 8. Mai 2026 (asymmetrisch): Der ESP-Komponenten-Patch (mainline commit f4c50a4034e6, SKBFL_SHARED_FRAG-Flag-Lösung) wurde am 7. Mai im netdev-Tree gemerged. Der RxRPC-Komponenten-Patch ist Stand jetzt noch unmerged upstream. Für die Distribution-Kernel-Pakete bedeutet das eine Phase mit Teil-Patches — die Modul-Blacklist-Mitigation bleibt der konsistente Schutz, bis beide Komponenten in den jeweiligen Distribution-Kerneln gelandet sind. Vulnerability-History für die Audit-Antwort: ESP seit Januar 2017 (cac2661c53f3), RxRPC seit Juni 2023 verwundbar.

Wer angreifen kann — und warum LPE im Mittelstand relevant ist

LPE-Schwachstellen sind kein reines Server-Thema. Drei Szenarien, in denen Dirty Frag Mittelständlern direkt zu schaffen macht:

• Entwickler-/CI-Maschinen mit shared accounts. Wer Build-Runner, Jump-Hosts oder Test-VMs mit mehreren Nutzern betreibt, hat ab heute eine Eskalations-Linie zwischen Standard-User und Root, die nicht da sein sollte.
• Container-Hosts mit Tenant-Trennung. Wenn ein Workload mit niedrigeren Rechten läuft (was bei sauberem Kubernetes-Setup die Regel ist), bricht Dirty Frag diese Trennung auf. Container-Escapes über Kernel-LPE sind klassisch.
• Web-Server mit kompromittierter Anwendung. Eine Anwendung, die selbst nur als www-data oder vergleichbar läuft, bekommt mit Dirty Frag den Hebel zur Vollkontrolle des Hosts — auch auf Systemen, deren Disziplin gerade darin bestand, Anwendungen unprivilegiert laufen zu lassen.

Die universale Reichweite (alle Kernel seit 2017) bedeutet: praktisch jede Produktiv-Linux-Maschine im Mittelstand ist heute betroffen, sofern nicht die Mitigation oder der zukünftige Patch bereits angewendet wurde.

Mitigation, wie UMich sie empfiehlt

Die Mitigation funktioniert über das Blockieren der drei verwundbaren Kernel-Module (esp4, esp6, rxrpc). Drei Schritte, die UMich als Sofortmaßnahme nennt:

1. Datei /etc/modprobe.d/dirtyfrag.conf mit folgenden drei Zeilen anlegen:
   install esp4  /bin/false
install esp6  /bin/false
install rxrpc /bin/false
2. Prüfen, ob die Module aktuell geladen sind: lsmod | egrep '^(esp4|esp6|rxrpc)'
3. Falls geladen, entladen: rmmod esp4 / rmmod esp6 / rmmod rxrpc

Das verhindert das Laden der verwundbaren Module beim nächsten Boot und entfernt sie sofort aus dem laufenden Kernel.

AWS-Hinweis: zwei Module zusätzlich blockieren. Das AWS Security Bulletin AWS-2026-027 empfiehlt, neben den drei UMich-Modulen auch ipcomp4 und ipcomp6 (IP-Compression-Module) zu blacklisten. Die zwei zususätzlichen Module sind nicht direkt Teil der Verkettung, aber Teil der gleichen xfrm-Modul-Familie und werden über denselben Netlink-Pfad auto-geladen — Defense-in-Depth gegen Auto-Load-Vektoren, die in einem Folge-Exploit nutzbar werden könnten. Plus zwei flankierende Schritte: per sysctl die Erstellung unprivilegierter User-Namespaces (user+net) deaktivieren und das Monitoring auf anomale setuid-Ausführungen schärfen. Für Amazon-Linux-Hosts ist diese erweiterte Liste die offizielle Empfehlung; auf anderen Distributionen ist sie als saubere Defense-in-Depth-Variante sinnvoll.

Mitigation auf NixOS — die deklarative Variante

Auf NixOS ist /etc/modprobe.d/ ein Symlink in den Nix-Store — manuelle Edits werden beim nächsten nixos-rebuild verworfen. Die korrekte Variante geht über die NixOS-Konfiguration:

{ pkgs, ... }:
{
  boot.extraModprobeConfig = ''
    install esp4 ${pkgs.coreutils}/bin/false
    install esp6 ${pkgs.coreutils}/bin/false
    install rxrpc ${pkgs.coreutils}/bin/false
  '';

  boot.blacklistedKernelModules = [ "esp4" "esp6" "rxrpc" ];
}

Drei Eigenschaften, die NixOS gegenüber der klassischen Distribution-Variante besser handhabt:

• Pfad-Korrektheit. Auf NixOS existiert /bin/false nicht — der Nix-Store-Pfad ${pkgs.coreutils}/bin/false ist der einzige Weg, der nach nixos-rebuild tatsächlich greift. Die UMich-Anleitung 1:1 copy-pasted bedeutet auf NixOS Fehler im modprobe-Log statt Mitigation.
• Atomar und rückrollbar. Nach sudo nixos-rebuild switch ist die Mitigation Teil der aktuellen System-Generation. Kommt der Distribution-Patch, einfach den Block aus der Config nehmen und neu builden. Bei Problemen: sudo nixos-rebuild --rollback switch. Keine vergessenen dirtyfrag.conf-Dateien, die irgendwann auf einem Host hängenbleiben.
• Multi-Host-Rollout deklarativ. Über deploy-rs, colmena, NixOps oder schlicht nixos-rebuild --target-host rollt die Konfiguration auf alle deklarierten Hosts in einer Welle. Die Audit-Antwort „welcher Host trägt die Mitigation, welcher nicht?“ ist eine Git-Frage, keine Stichproben-Frage.

Aktiv geladene Module entfernen läuft trotzdem klassisch via sudo rmmod esp4 esp6 rxrpc — das ist Linux-generisch und unabhängig vom Distribution-Pattern.

Trade-offs der Mitigation — was kaputtgeht

IPsec. Die Module esp4 und esp6 sind Teil der IPsec-Infrastruktur für IPv4 und IPv6. Wer site-to-site VPNs oder Host-to-Host-IPsec einsetzt, verliert mit der Mitigation den ESP-Pfad. Dort, wo IPsec produktiv genutzt wird, muss vor der Mitigation eine alternative Konnektivität stehen oder die Anwendung kurzzeitig unterbrochen werden.

kAFS. Das Modul rxrpc ist die Transport-Schicht der kernel-AFS-Implementierung. Wer kAFS produktiv nutzt, verliert den Filesystem-Zugriff. Die OpenAFS-Implementierung ist von der Mitigation ausdrücklich nicht betroffen — das ist im Mittelstand auch der häufigere Fall.

UMich gibt eine deutliche Hinweis-Warnung: Bei Systemen, auf denen die Module bereits geladen sind, sollte die Mitigation zuerst auf nicht-kritischen Systemen getestet werden, bevor sie produktiv ausgerollt wird. Das ist standard-disciplinarisch und gilt erst recht für alles, was IPsec oder AFS in irgendeiner Form berührt.

Wie wir das selbst handhaben

Eine Empfehlung ohne eigene Praxis-Erfahrung ist hohle Beratung. Wir nutzen, was wir bauen.

Bei der UMich-Meldung am 7. Mai haben wir intern das gleiche Pattern wie bei Copy Fail durchgespielt: SBOM-Abgleich über alle Customer-Stacks, Linux-Hosts mit Kernel-Versionen ab 2017 (also praktisch alle) als betroffen markiert, IPsec- und kAFS-Nutzung pro Stack geprüft. Die meisten Customer-Stacks haben weder IPsec im Kernel-Stack (Site-to-Site-Tunnel laufen über WireGuard oder dedizierte VPN-Appliances) noch kAFS (OpenAFS ist im DACH-Mittelstand der seltene Standard, kAFS noch seltener). Damit ist die Mitigation für die meisten Stacks risikoarm. Die wenigen Sonderfälle laufen über die etablierte Welle: nicht-kritische Pre-Prod zuerst, dann Staging, dann Produktion mit definiertem Wartungsfenster.

Im eigenen Stack: Mitigation auf den nicht-kritischen Build-Runnern und Test-VMs / Test-VPS am 8. Mai im Tagesverlauf, Production-Hosts am 8. Mai. Kernel-Patch wird eingespielt, sobald die Distribution (Debian-stable, Ubuntu LTS, RHEL-Familie) ihn auf den üblichen Wegen ausliefert; das ist der Moment, in dem die Mitigation wieder zurückgenommen werden kann.

Drei Maßnahmen-Tiefen für Ihren Stack

Kurzfristig (heute oder morgen):

• Inventur Linux-Hosts: welche Maschinen mit Kernel ab 2017? Praktisch alle. Liste machen, geordnet nach Kritikalität.
• IPsec/kAFS-Prüfung pro Host: ip xfrm state für IPsec, lsmod | grep -E 'kafs|rxrpc' für kAFS. Die meisten Mittelstand-Stacks sind in beiden Punkten clean.
• Mitigation auf nicht-kritischen Hosts ausrollen, lsmod-Prüfung, rmmod falls nötig.

Mittelfristig (nächste 2 Wochen):

• Mitigation auf Produktiv-Hosts ausrollen, in geplanten Wartungsfenstern. Für Hosts mit IPsec: alternative Konnektivität oder kurzfristige Downtime einplanen.
• Distribution-Watch: sobald der Kernel-Patch in Debian/Ubuntu/RHEL-Streams ankommt, eingespielen. Mitigation dann zurücknehmen, falls IPsec wieder aktiviert werden soll.
• Audit-Trail: dokumentieren, welcher Host wann mitigiert/gepatcht wurde. Das ist die Voraussetzung dafür, dass der CRA-Reporting-Pfad ab September 2026 überhaupt belastbar ist.

Strategisch (nächstes Quartal):

• Wenn die laufende SBOM-Pflege dieses Mal nicht innerhalb von Stunden Klarheit über betroffene Hosts gegeben hat, ist das ein Indikator: SBOM-Routine schlägt jede Improvisation, wenn die nächste universelle LPE kommt. Und sie kommt.
• IPsec-Strategie evaluieren: Wer IPsec heute via Kernel-Module einsetzt, sollte prüfen, ob WireGuard oder eine dedizierte VPN-Appliance die robustere Variante wäre. Nicht wegen Dirty Frag im Speziellen, sondern weil diese Schicht regelmäßig im Visier ist.
• Patch-Pipeline-Tempo: kann Ihre Pipeline einen Critical-Kernel-Patch in 7 Tagen ausliefern, ohne Hero-Modus? Wenn nicht, ist das die strategische Lücke, die hier zwischen den Zeilen sichtbar wird.