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

TL;DR — die 90-Sekunden-Zusammenfassung

Betroffen?

Alle Linux-Kernel seit 2017, einschließlich Kernel 7.0.4. Bestätigt: Ubuntu 24.04.4, RHEL 10.1, CentOS Stream 10, AlmaLinux 10, Fedora 44, openSUSE Tumbleweed. SLES 11 SP4 LTSS Extreme Core nicht betroffen.

Risiko?

Universelle lokale Privileg-Eskalation bis Root über die Verkettung zweier Page-Cache-Write-Lücken in xfrm-ESP und RxRPC. Public-PoC verfügbar.

Sofortmaßnahme?

Module esp4, esp6, rxrpc per /etc/modprobe.d/dirtyfrag.conf blockieren und mit rmmod entladen. AWS empfiehlt zusätzlich ipcomp4, ipcomp6 und das Deaktivieren unprivilegierter User-Namespaces.

Empfehlung?

Mittelstand: Modul-Blacklist sofort, Distribution-Patch innerhalb von 7 Tagen. Enterprise/Kubernetes: zusätzlich Detection-Hooks auf XFRM-Netlink und Worker-Node-Image rebuilden. NixOS: deklarative Variante über boot.blacklistedKernelModules.

Kritikalität?

Hoch — CVSS 7.8 CISA, 8.8 SUSE (Attack Complexity divergiert). Siehe Badge im Seitenkopf.

 

Was ist das Problem?

Dirty Frag (CVE-2026-43284) wird seit dem 8. Mai 2026 offiziell getrackt (CVE-Nummer zuerst von AlmaLinux vergeben). 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 trifft — sie sind die Eintrittstür zur Verkettung, auch auf Hosts, die selbst weder IPsec noch kAFS aktiv einsetzen.

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 war. Inzwischen (Stand 11. Mai 2026) liegt der ESP-Patch in den meisten Distributionen vor, der RxRPC-Patch ist Stand heute teilweise noch unmerged — die Modul-Blacklist für rxrpc bleibt deshalb bis auf Weiteres notwendig.

Wer ist betroffen?

Die Reichweite ist außergewöhnlich breit, weil die zwei verketteten Lücken in Kernel-Pfaden sitzen, die in praktisch jedem Mainstream-Linux ausgeliefert werden. Nicht das Userland entscheidet, sondern der Kernel und das Auto-Load-Verhalten der Module über XFRM-Netlink.

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

• Entwickler- und 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 — wir haben das beim Copy-Fail-Post ausführlicher hergeleitet.
• 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 betroffen, sofern nicht Mitigation oder Patch bereits angewendet wurden.

Auswirkungen

Dirty Frag ist eine lokale Privileg-Eskalation. RCE oder Remote-Eskalation sind nicht direkt möglich, der Exploit setzt eine bestehende Code-Ausführung im User-Space voraus. Aber genau diese Voraussetzung ist im Mittelstand-Stack so niederschwellig zu erreichen, dass die Bewertung trotzdem im hohen Bereich liegt.

Die CVSS-Bewertungen weichen voneinander ab, je nachdem, wer wertet:

SUSE setzt Attack Complexity auf Low (CISA: High), bei gleichem Local-Vektor und Scope-Changed. Beide stufen die Lücke als Important ein. Wir folgen in der internen Risikobewertung der SUSE-Lesart — wegen des Public-PoC und der trivialen Auto-Load-Voraussetzung ist Attack Complexity in der Praxis Low, nicht High.

Was das operativ heißt:

• Container-Escape effektiv möglich. Jeder kompromittierte Pod auf einem ungepatchten Host kann Root auf der Node erlangen. Damit ist die gesamte Worker-Node und mittelbar das Cluster offen.
• CI/CD-Runner als Hochrisiko-Ziel. Self-hosted GitHub-Runner, GitLab-Runner und Jenkins-Agents führen regelmäßig nicht vertrauenswürdigen Code aus. Eine kompromittierte Pipeline reicht — wir haben an anderer Stelle ausführlich beschrieben, warum die CI-Pipeline der größte Verdichtungspunkt für Eskalationen im Stack ist.
• Shared-Hosting und Multi-Tenant-VPS. Klassischer Eintrittspunkt für Cross-Tenant-Eskalation.
• Compliance-Folgen. Wer unter NIS-2, BSI-Grundschutz, ISO 27001 oder DORA betrieben wird, hat eine Vorfall-Bewertungs-Pflicht, sobald ein Exploit öffentlich verfügbar ist — unabhängig von der Detection-Lage. Für den CRA-Reporting-Pfad ab September 2026 wird der dokumentierte Patch- und Mitigation-Stand zur Audit-Voraussetzung.

Business-seitig: Downtime durch Reboot ist die wahrscheinlichste direkte Auswirkung. Datenverlust ist bei sauberer Mitigation kein realistisches Szenario; die Reputationsfrage stellt sich, wenn ein Vorfall vor dem Patch passiert. Die acht Tage zwischen Disclosure (7.5.) und erstem Distribution-Patch (AWS, 9.5.) sind genau das Zeitfenster, in dem Modul-Blacklist und PoC-Validierung den Unterschied machen.

Mitigation und Sofortmaßnahmen

Die kurze Antwort: Distribution-Patch einspielen und neu starten. Wo der Patch noch nicht da ist (oder das Wartungsfenster später liegt), die verwundbaren Kernel-Module blocken. Beide Workarounds wirken zur Laufzeit.

Quick-Start (Copy/Paste)

Für Linux-Hosts ohne IPsec und ohne kAFS — die DACH-Mittelstand-Mehrheit — reichen vier Zeilen für die sofortige Stopgap-Mitigation:

# 1. Module live entladen, falls geladen
sudo modprobe -r esp4 esp6 rxrpc ipcomp4 ipcomp6 2>/dev/null

# 2. Fünf-Modul-Blacklist persistent setzen (AWS-Empfehlung)
cat <<EOF | sudo tee /etc/modprobe.d/dirtyfrag.conf
install esp4     /bin/false
install esp6     /bin/false
install rxrpc    /bin/false
install ipcomp4  /bin/false
install ipcomp6  /bin/false
EOF

# 3. Unprivilegierte User-Namespaces deaktivieren
echo -e "kernel.unprivileged_userns_clone = 0\nuser.max_user_namespaces = 0" | sudo tee /etc/sysctl.d/99-dirtyfrag.conf
sudo sysctl --system

# 4. Validieren, dass die Module nicht mehr laden
lsmod | egrep '^(esp4|esp6|rxrpc|ipcomp4|ipcomp6)' || echo "Mitigation aktiv."

Auf NixOS / Talos / Flatcar gilt die deklarative Variante (siehe weiter unten). Für Hosts mit produktivem IPsec oder kAFS gilt der Trade-off-Block am Sektionsende — erst Alternativ-Pfad sicherstellen, dann mitigieren.

Patch einspielen, wenn verfügbar

# Amazon Linux 2023 (Patch verfügbar seit 09.05.2026)
sudo dnf upgrade -y kernel
sudo reboot

# Amazon Linux 2
sudo yum update -y kernel
sudo reboot

# SUSE Linux Enterprise Real Time 15 SP7 (Live-Patch released)
sudo zypper patch --category security
# Reboot-frei für kernel-livepatch-SLE15-SP7-RT_Update_13

# Andere Mainstream-Distros: laufende Backports beobachten
# Debian/Ubuntu: apt list --upgradable | grep linux-image
# RHEL/AlmaLinux/Rocky: dnf check-update kernel

Modul-Blacklist (UMich-Variante, drei Module)

Die UMich-Empfehlung blockt die drei direkt verwundbaren Module:

# /etc/modprobe.d/dirtyfrag.conf anlegen
cat <<EOF | sudo tee /etc/modprobe.d/dirtyfrag.conf
install esp4  /bin/false
install esp6  /bin/false
install rxrpc /bin/false
EOF

# Prüfen, ob Module aktuell geladen sind
lsmod | egrep '^(esp4|esp6|rxrpc)'

# Falls geladen, entladen
sudo rmmod esp4 esp6 rxrpc

AWS-Erweiterung (fünf Module plus User-Namespace-Sperre)

Das AWS Security Bulletin AWS-2026-027 erweitert die Blacklist um ipcomp4 und ipcomp6 (gleiche xfrm-Modul-Familie, Auto-Load über denselben Netlink-Pfad). Plus zwei flankierende Schritte:

# Erweiterte Modul-Blacklist
cat <<EOF | sudo tee /etc/modprobe.d/dirtyfrag-aws.conf
install esp4     /bin/false
install esp6     /bin/false
install rxrpc    /bin/false
install ipcomp4  /bin/false
install ipcomp6  /bin/false
EOF

# Unprivilegierte User-Namespaces deaktivieren
cat <<EOF | sudo tee /etc/sysctl.d/99-dirtyfrag.conf
kernel.unprivileged_userns_clone = 0
user.max_user_namespaces = 0
EOF
sudo sysctl --system

# Monitoring auf anomale setuid-Ausführungen schärfen
# (auditd, Falco, Tetragon — siehe Detection-Sektion)

Für Amazon-Linux-Hosts ist diese erweiterte Liste die offizielle Empfehlung, auf anderen Distributionen ist sie als saubere Defense-in-Depth-Variante sinnvoll.

NixOS — 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
    install ipcomp4 ${pkgs.coreutils}/bin/false
    install ipcomp6 ${pkgs.coreutils}/bin/false
  '';

  boot.blacklistedKernelModules = [
    "esp4" "esp6" "rxrpc" "ipcomp4" "ipcomp6"
  ];

  boot.kernel.sysctl = {
    "kernel.unprivileged_userns_clone" = 0;
    "user.max_user_namespaces" = 0;
  };
}

# anschließend
sudo nixos-rebuild switch

Drei Eigenschaften, die NixOS gegenüber dem klassischen Distribution-Pattern besser handhabt:

• Pfad-Korrektheit. Auf NixOS existiert /bin/false nicht — der Nix-Store-Pfad 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.
• Multi-Host-Rollout deklarativ. Über deploy-rs, colmena, NixOps oder nixos-rebuild --target-host rollt die Konfiguration in einer Welle. Die Audit-Antwort „welcher Host trägt die Mitigation, welcher nicht?“ ist eine Git-Frage, keine Stichproben-Frage.

Trade-offs — 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 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 ausdrücklich nicht betroffen, das ist im Mittelstand auch der häufigere Fall.

IP-Compression.ipcomp4 und ipcomp6 sind selten produktiv im Einsatz; die zusätzliche Blockade ist meist folgenlos. Wer IPComp tatsächlich nutzt (in Kombination mit IPsec auf bandbreitenkritischen Links), muss vor der Mitigation einen Alternativ-Pfad bauen.

Rollback. Modul-Blacklist lässt sich mit sudo rm /etc/modprobe.d/dirtyfrag*.conf und einem Reboot zurückdrehen. Sysctl-Stopgap: sudo rm /etc/sysctl.d/99-dirtyfrag.conf && sudo sysctl --system.

Detection und Prüfung

Detection bei Dirty Frag beantwortet fünf operative Kernfragen:

• Welche Module sind auf welchen Hosts geladen? — Inventur über lsmod und SBOM.
• Welche Hosts sind exponiert? — Prüfung gegen ip xfrm state und Auto-Load-Pfad.
• Wie prüfen wir Container-Hosts? — Tetragon/Falco-Hooks auf NETLINK_XFRM und AF_RXRPC aus Container-Prozessen.
• Wie validieren wir die Mitigation? — Reproduktion des Public-PoC vor und nach dem Stopgap, isolierte Test-VM, Exit-Code-Vergleich.
• Wie erkennen wir aktive Ausnutzung? — auditd auf XFRM-Netlink-Socket-Creation, Tetragon-Korrelation init_module nach NETLINK_XFRM, Syslog-Pattern auf anomale setuid-Ausführungen (laut AWS-Empfehlung).

Drei Ebenen in der konkreten Umsetzung: Prüfen, ob die verwundbaren Module geladen sind; prüfen, ob der XFRM-Auto-Load-Pfad genutzt wurde; prüfen, ob die Mitigation wirklich greift.

Modul- und Kernel-Status

# Sind die fünf relevanten Module geladen?
lsmod | egrep '^(esp4|esp6|rxrpc|ipcomp4|ipcomp6)'

# Kernel-Version prüfen (alles ab 2017 ist betroffen)
uname -r

# Distribution-Patch-Datum nachvollziehen
dpkg -l linux-image-$(uname -r) | tail -1   # Debian/Ubuntu
rpm -qi kernel-$(uname -r | sed 's/\.[^.]*$//')  # RHEL/AlmaLinux

# Prüfen, ob die XFRM-Symbole im laufenden Kernel überhaupt exportiert sind
grep -E '(xfrm_user|esp_input|rxrpc_recvmsg)' /proc/kallsyms | head

# Auto-Load-Modulkette prüfen (welche Module hängen am xfrm-Stack?)
modprobe --show-depends esp4 esp6 rxrpc ipcomp4 ipcomp6

# IPsec aktiv? (Trade-off-Prüfung vor Mitigation)
sudo ip xfrm state
sudo ip xfrm policy

Audit-Logs auf XFRM-Netlink

# auditd auf den XFRM-Netlink-Socket schärfen
sudo auditctl -a always,exit -F arch=b64 -S socket -F a0=16 -F a1=3 -k xfrm-netlink

# rückblickend prüfen
sudo ausearch -k xfrm-netlink -ts recent

# rxrpc-Socket-Aktivität (AF_RXRPC = 33) im laufenden System
sudo ss -A inet,inet6 -p | grep -i rxrpc

Falco-Rule als Alternative zu Tetragon

Wer Falco statt Tetragon einsetzt, deckt denselben Signal-Pfad mit zwei kombinierten Rules ab — eine für den XFRM-Netlink-Eintritt, eine für den RxRPC-Socket. Beide haben in regulären Application-Containern keinen Use-Case:

- rule: Suspicious XFRM netlink socket from container
  desc: Detect creation of NETLINK_XFRM sockets from container processes — likely Dirty Frag entry probe
  condition: >
    evt.type = socket and
    container.id != host and
    evt.arg[0] = 16 and
    evt.arg[2] = 6
  output: >
    NETLINK_XFRM socket opened from container
    (pod=%k8s.pod.name ns=%k8s.ns.name container=%container.name
     proc=%proc.cmdline pid=%proc.pid user=%user.name)
  priority: WARNING
  tags: [container, mitre_privilege_escalation, cve-2026-43284]

- rule: Suspicious AF_RXRPC socket from container
  desc: Detect creation of AF_RXRPC (kAFS) sockets from container processes — second stage of Dirty Frag
  condition: >
    evt.type = socket and
    container.id != host and
    evt.arg[0] = 33
  output: >
    AF_RXRPC socket opened from container
    (pod=%k8s.pod.name ns=%k8s.ns.name container=%container.name
     proc=%proc.cmdline pid=%proc.pid user=%user.name)
  priority: CRITICAL
  tags: [container, mitre_privilege_escalation, cve-2026-43500]

Falco läuft als DaemonSet, Tetragon-TracingPolicies sind über CRDs deklariert — in Clustern, in denen Cilium ohnehin läuft, ist Tetragon der direktere Weg, sonst Falco. Beide schreiben die Treffer in JSON-Logs, die ein SIEM auf Pod-Identität aggregiert. Die zweite Rule (AF_RXRPC) sollte als CRITICAL geführt werden, weil RxRPC im Mittelstand-Bestand praktisch nie produktiv genutzt wird — Treffer dort sind fast immer Eskalations-Versuche.

Tetragon-Hook auf den Exploit-Pfad

Der Public-PoC löst zwei Syscall-Sequenzen aus: socket(AF_NETLINK, ..., NETLINK_XFRM) mit nachfolgendem Modul-Load — plus, falls die zweite Stufe läuft, socket(AF_RXRPC). Beide haben in regulären Application-Containern keinen Use-Case.

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: detect-dirty-frag-sequence
spec:
  kprobes:
    - call: "__x64_sys_socket"
      syscall: true
      args:
        - index: 0
          type: "int"
        - index: 2
          type: "int"
      selectors:
        - matchArgs:
            - index: 0
              operator: "Equal"
              values: ["16"]   # AF_NETLINK
            - index: 2
              operator: "Equal"
              values: ["6"]    # NETLINK_XFRM
        - matchArgs:
            - index: 0
              operator: "Equal"
              values: ["33"]   # AF_RXRPC
    - call: "__x64_sys_init_module"
      syscall: true

Korreliert in der SIEM-Pipeline (oder direkt im Tetragon-Output, mit pid/tgid als Schlüssel): Wenn ein Pod ohne IPsec- oder kAFS-Bedarf einen XFRM-Netlink-Socket öffnet und kurz danach ein init_module-Call auf dem Host feuert, ist das ein Dirty-Frag-Eintrittssignal mit hoher Trefferwahrscheinlichkeit.

Validierung der Mitigation

Wir betrachten einen Host erst als bereinigt, wenn der Public-PoC nach der Mitigation fehlschlägt. Der Repo-Stand ist github.com/V4bel/dirtyfrag. Der PoC wird in einer isolierten User-Session ausgeführt, das Ergebnis (Exit-Code, ggf. UID-Wechsel) protokolliert. Erst dann bekommt der Host das Bereinigungs-Flag in unserer Inventur.

# PoC in isolierter Test-Session
git clone github.com/V4bel/dirtyfrag /tmp/dirtyfrag
cd /tmp/dirtyfrag
# Setup laut README
./run_exploit.sh
# Erwartung nach Mitigation: Exit != 0, kein root-Shell-Drop

Wichtig: Die PoC-Reproduktion gehört nicht auf Produktiv-Hosts. Für die Validierung braucht es eine isolierte Test-VM mit identischer Distribution und Kernel-Version.

Betreiberempfehlung

Die Empfehlung hängt vom Setup ab. Vier Szenarien, vier Antworten — mit einem operativen Entscheidungsraster vorab:

Entscheidungsraster: Wann jetzt mitigieren, wann Wartungsfenster?

• Sofort mitigieren (heute), wenn der Host Multi-Tenant-Workloads fährt, CI/CD-Runner hält, Shared Worker betreibt, unprivilegierte Mehrnutzer-Sessions zulässt oder eine bereits kompromittierte Anwendung trägt. Der Microsoft-Active-Attack-Status macht diese Kategorie zur Sofort-Pflicht.
• Wartungsfenster möglich (nächste 48 Stunden), wenn der Host als isoliertes Single-Tenant-System läuft, keine fremden User Code ausführen und IPsec sowie kAFS dokumentiert nicht produktiv genutzt werden.
• Patch-Welle der nächsten 7 Tage reicht, wenn der Host eine reine Workstation oder ein abgeschotteter Single-User-Server ist und keine Netzwerk-exponierten Dienste mit unbekanntem Code laufen.
• IPsec-Host? Erst Alternativ-Pfad sicherstellen. Wer ESP-Tunnel produktiv fährt, darf nicht blind mitigieren — WireGuard-Failover oder Wartungsfenster zwingend.

Diese vier Linien finden sich in den Szenarien unten konkretisiert wieder.

Mittelstand mit klassischen VMs oder Bare-Metal

Modul-Blacklist sofort, Distribution-Patch im nächsten Wartungsfenster (spätestens binnen 7 Tagen). Wer kein definiertes Patch-Fenster betreibt: jetzt einen festen wochenpunkt etablieren. Die Blacklist als Stopgap reicht für 24 bis 72 Stunden, ist aber kein Dauerzustand. IPsec-Prüfung vor der Mitigation, dann Stufe 1 Pre-Prod, Stufe 2 Production.

Shared Hosting und Multi-Tenant-VPS

Höchste Priorität. Ein Multi-Tenant-Host mit kompromittiertem Kunden-Account ist mit Dirty Frag in zwei Schritten weg — unprivilegiertes Konto → LPE → cross-tenant Eskalation. Sofort die Fünf-Modul-Blacklist ausrollen, plus User-Namespace-sysctl. Verwendet der Hosting-Stack klassische cgroups-basierte Isolation, gilt die K8s-Lateral-Movement-Logik (siehe Copy Fail in Kubernetes) sinngemäß.

Enterprise mit Change-Management

Parallel zwei Spuren fahren: Standard-Patch-Pipeline für Production via Wartungsfenster, Stopgap-Mitigation (Modul-Blacklist plus sysctl) für alle Hosts, die nicht innerhalb von 48 Stunden gepatcht werden können. Compliance-Dokumentation parallel führen: betroffene Hosts, Stopgap-Stand, Patch-Stand, Validierungs-Ergebnis. Auditierbar.

Kubernetes-Cluster (self-managed und Managed)

Entscheidungsraster für Kubernetes-Hosts:

• Multi-Tenant-Cluster, Shared Worker oder CI/CD-Runner-Nodes → Worker-Image mit Fünf-Modul-Blacklist sofort rebuilden, rolling drain.
• Managed-K8s (AKS/EKS/GKE) auf Amazon Linux oder AlmaLinux Base → Provider-Channel auf den gepatchten Stand setzen, Node-Pool rolling ersetzen.
• Managed-K8s auf Ubuntu/Debian-Base → Modul-Blacklist per cloud-init oder Bootstrap-Skript halten, bis Provider-Image patched ist.
• Privileged DaemonSets aus geteilter Base-Layer mit Application-Pods → Lateral-Movement-Pfad prüfen (analoge Logik wie bei Copy Fail in Kubernetes).

Bei self-managed Clustern Worker-Node-Image mit den Modul-Blacklist-Einträgen neu bauen, dann pro Node kubectl drain <node> --ignore-daemonsets --delete-emptydir-data, Reboot, kubectl uncordon. PodDisruptionBudgets vorher prüfen. Bei Managed-K8s (AKS, EKS, GKE) den Provider-Channel auf den gepatchten Node-Image-Stand setzen und die Node-Pools rolling ersetzen lassen — EKS-Kunden auf Amazon Linux 2023 sind seit 09.05. über das Standard-Upgrade-Pattern abgedeckt. Detection-Hooks (siehe Detection-Sektion) auf den XFRM-Netlink-Pfad scharfschalten, bis 100 Prozent der Nodes gepatcht sind. PodSecurity-Standard mindestens auf restricted.

VPN- und IPsec-Gateways

Trade-off zuerst validieren. Bevor esp4/esp6 gesperrt werden, muss klar sein, ob Site-to-Site-Tunnel oder Host-to-Host-IPsec produktiv laufen. Drei Pfade: erstens, WireGuard-Failover-Pfad auf Layer 3 hochfahren und IPsec-Modul-Blacklist erst nach erfolgreichem Routing-Switch ausrollen; zweitens, gepatchten Kernel direkt einspielen (Amazon Linux / AlmaLinux / Rocky verfügbar) und Modul-Blacklist nur für rxrpc/ipcomp* halten; drittens, Wartungsfenster mit kurzem Tunnel-Down einplanen und während des Fensters Stopgap + Reboot kombiniert ausführen. Detection-Hook auf XFRM-Netlink bleibt parallel scharf, weil ein Angreifer mit anstehender Lateral-Movement-Welle gerade Gateways angreift.

NixOS-Hosts und deklarative Stacks

Wer NixOS oder einen anderen deklarativen Host-Stack (Talos, Flatcar) betreibt, hat zwei Vorteile, die hier zählen. Erstens: Die Mitigation ist eine Code-Änderung in configuration.nix, kein Konfigurations-Eingriff am Live-System — sie geht durch Code-Review und CI. Zweitens: Die vorige Generation bleibt im Bootloader stehen. Wenn die Modul-Blacklist eine produktive Funktion bricht (z.B. IPsec auf einem Host, der das doch nutzt), reicht ein Reboot in die alte Generation. Diese Reversibilität fehlt klassischen apt/dnf-Hosts.

Was wir konkret getan haben

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.

• SBOM-Inventur am 7. Mai. Inventur über unsere SBOM-Pipeline: welcher Host fährt welchen Kernel, welche Distribution, welches Patch-Datum. Plus: ip xfrm state-Auswertung für IPsec, lsmod | grep -E 'kafs|rxrpc' für kAFS. Innerhalb von 90 Minuten Klarheit über jeden Host im Park.
• IPsec- und kAFS-Prüfung pro Customer-Stack. 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 war die Mitigation für die meisten Stacks risikoarm.
• Stopgap-Mitigation am 7. Mai (Pre-Prod) und 8. Mai (Production). Drei-Module-Blacklist auf nicht-kritischen Build-Runnern und Test-VMs am Tagesverlauf des 7. Mai, Production-Hosts am 8. Mai im Wartungsfenster. NixOS-Hosts liefen über die deklarative Variante (siehe Mitigation-Sektion), klassische Distributions-Hosts über die UMich-Anleitung.
• AWS-Erweiterung am 8. Mai, Nachmittag. Nach dem AWS-Bulletin ipcomp4, ipcomp6 nachgezogen, plus User-Namespace-sysctl gesetzt. Fünf-Module-Blacklist statt drei.
• Validierung pro Host. V4bel/dirtyfrag-PoC gegen die mitigierten Hosts in einer isolierten Test-VM laufen lassen. Erst wenn der Exploit fehlschlägt, gilt der Host für uns als bereinigt.
• Distribution-Patch-Nachzug. Ab 9. Mai 2026 für Amazon-Linux-Hosts über Standard-Update-Pipeline. Sobald der Patch in den jeweiligen Channels ankommt (Debian-stable, Ubuntu LTS, RHEL-Familie), wird er eingespielt; Stopgap wird erst nach erfolgreicher PoC-Validierung gegen den gepatchten Kernel zurückgenommen. Patch und Stopgap überlappen bewusst.
• Was wir bewusst nicht gemacht haben. Keine IPsec-Hosts ohne alternative Konnektivität mitigiert. Keine generischen Hardening-Aktionen „bei der Gelegenheit“, damit die Validierung der eigentlichen Mitigation sauber bleibt.

Diese Routine ist genau das, was wir für Kunden im Rahmen von DevSecOps as a Service und der Externen IT-Abteilung betreiben. Methodisch hängen Dirty Frag, Copy Fail und das Image-Audit nach IDS-Alarm am gleichen Geflecht: SBOM-Routine, isolierte PoC-Validierung, dokumentierter Rollout.

Technischer Deep Dive

Dirty Frag ist eine Verkettung von zwei separaten Page-Cache-Write-Lücken in unterschiedlichen Subsystemen des Linux-Kernels. Erst die Kette macht die universelle LPE möglich, einzelne Teile wären für sich genommen weniger ausnutzbar.

Komponente 1: xfrm-ESP-Fast-Path

Die ESP-Implementierung in net/ipv4/esp4.c und net/ipv6/esp6.c nutzt seit Commit cac2661c53f3 (Januar 2017) einen Fast-Path mit MSG_SPLICE_PAGES. Daten werden ohne Copy-on-Write über Page-Splicing in den ESP-Encapsulation-Pfad gefüttert. Das spart CPU im IPsec-Throughput und war damals eine saubere Optimierung.

Das Problem: Unter bestimmten Race-Conditions schreibt der ESP-Pfad in eine Page, die zur Page Cache eines anderen Files gehört. Weil kein COW ausgelöst wird, landet die Modifikation direkt im geteilten Page-Cache-Eintrag — ohne Disk-Write, ohne Spur im Filesystem. Das ist konzeptionell vergleichbar mit dem K8s-Variante-Vektor bei Copy Fail: shared Page Cache wird zur Manipulations-Schicht.

Der Mainline-Fix kam am 7. Mai 2026 als Commit f4c50a4034e6 in den netdev-Tree: ein neues SKBFL_SHARED_FRAG-Flag erzwingt COW, wenn die Page geteilt ist. Distribution-Backports laufen seitdem.

Komponente 2: RxRPC-Transport

net/rxrpc/ ist die Kernel-Implementierung des Rx-RPC-Protokolls, vor allem als Transport-Schicht für kAFS (kernel-AFS). RxRPC nutzt eine ähnliche Page-Splicing-Mechanik wie ESP — mit denselben strukturellen Folgen, sobald die Implementierung in einen geteilten Buffer schreibt.

Die RxRPC-Komponente ist seit Juni 2023 verwundbar, der entsprechende Upstream-Patch ist Stand 11. Mai 2026 teilweise noch unmerged. Genau deshalb bleibt die Modul-Blacklist für rxrpc auch nach dem ESP-Patch notwendig.

Eintrittstor: XFRM-User-Netlink-Auto-Load

Der eigentliche Trick — und der Grund, warum praktisch jeder Host betroffen ist — sitzt im XFRM-User-Netlink-Interface. Ein unprivilegierter Prozess kann über einen NETLINK_XFRM-Socket eine Operation anfordern, für die der Kernel das ESP- oder RxRPC-Modul nachladen muss. Der Auto-Load greift, selbst wenn der Host weder IPsec noch kAFS produktiv einsetzt. Das ist auch die Begründung, warum die Mitigation genau drei (UMich) bzw. fünf (AWS) Module trifft: nicht die Nutzungs-Pfade, sondern die Eintrittsbarriere wird verschlossen.

Warum ipcomp4 und ipcomp6 dazu gehören

Die ipcomp4- und ipcomp6-Module gehören zur gleichen xfrm-Modul-Familie wie ESP und werden über denselben Netlink-Pfad auto-geladen. Sie sind nicht direkt Teil der heute bekannten Verkettung, aber sie sind ein plausibler Folge-Exploit-Vektor, falls in der gleichen Familie eine weitere Page-Cache-Write-Lücke gefunden wird. AWS empfiehlt das präventive Blocken aus genau diesem Grund. Wer den Aufwand des Audits einmal hatte, sollte die zwei Module beim nächsten Mal nicht erneut entdecken müssen.

Aspekte für die Bewertung

• Kein Capability-Bedarf. NETLINK_XFRM-Socket-Erstellung braucht weder CAP_NET_ADMIN noch CAP_SYS_MODULE. Jeder unprivilegierte Prozess kann den Pfad erreichen.
• Auto-Load schlägt bloße Modul-Entladung. Ein rmmod esp4 ohne Blacklist hält nur, bis der nächste XFRM-Netlink-Call das Modul nachlädt. Deshalb ist die install ... /bin/false-Variante notwendig: sie blockt den Auto-Load.
• Container-Namespaces helfen nicht. User-Namespaces isolieren UID-Mappings, aber nicht den Kernel-Code-Path. Das ist die gleiche strukturelle Schwäche wie bei Copy Fail — Container-Isolation ist eine User-Space-Konstruktion, durchgesetzt vom Kernel selbst.
• Trade-off-Vector ipcomp. Wer IPComp produktiv nutzt (selten, aber im Mittelstand-Bestand gelegentlich auf bandbreitenkritischen Site-to-Site-Tunneln), verliert die Funktion. Die Defense-in-Depth-Variante ist nicht kostenlos, nur sehr günstig.

Fazit

Dirty Frag ist eine universelle Linux-LPE — alle Kernel seit 2017 betroffen, Public-PoC verfügbar, Auto-Load der verwundbaren Module ohne Capability-Bedarf. Die belastbare Antwort liegt im Distribution-Patch (seit 09.05. für Amazon Linux verfügbar, andere Distros folgen), bis dahin in der Modul-Blacklist für drei (UMich) oder fünf (AWS) Module plus User-Namespace-Sperre.

Operativ wichtiger als die Einzel-CVE ist das Muster dahinter: zum zweiten Mal in acht Tagen schreibt eine breite Kernel-Lücke in den geteilten Page Cache und lässt sich über einen vermeintlich harmlosen Netlink-Pfad auslösen. Wer einen klaren Patch-Rhythmus, eine belastbare SBOM-Inventur und ein Detection-Setup auf XFRM-Netlink-Calls hat, beantwortet die Frage „wer ist betroffen?“ in Stunden, nicht Tagen. Wer die Mitigation deklarativ ausrollt (NixOS, Talos, Flatcar), hat den Bonus, dass die Rücknahme nach dem Patch eine Code-Änderung ist, kein Stichproben-Audit.

Realistische Risiko-Einordnung: Hoch für Multi-Tenant-Hosts, CI/CD-Runner und Kubernetes-Worker. Mittel für saubere Single-Tenant-Production-VMs. Niedrig für abgeschottete Single-User-Workstations. Die Disziplin, die Dirty Frag verlangt, ist keine Ausnahme — sie wird die nächste universelle LPE in genau dieser Form wieder verlangen. Der Stack, der heute strukturiert antwortet, antwortet beim nächsten Mal genauso, nur schneller.