Kernel-Lücke 'Dirty Frag' (CVE-2026-43284)

linux security

Red Hat hat das Bulletin RHSB-2026-003 "Dirty Frag" für eine lokale Privilege Escalation im Linux-Kernel-Netzwerk-Subsystem veröffentlicht. Im Bulletin zusammengefasst: CVE-2026-43284 im IPsec-ESP-Pfad (Dirty Frag) und CVE-2026-46300 in der ESP-in-TCP-Variante (Fragnesia). Red Hat klassifiziert beide als Important. Betroffen sind RHEL 8, 9 und 10 sowie OpenShift Container Platform 4. Patches werden laut Bulletin beschleunigt vorbereitet. Bis sie eingespielt sind, gilt eine der beiden offiziellen Mitigationen.

Update 2026-05-09: Rocky Linux hat das optionale Security-Repository für Hot-Fixes ausserhalb der regulären BaseOS-Errata bereitgestellt. Der Dirty-Frag-Kernel-Hot-Fix liegt drin: für Rocky 9 als kernel-5.14.0-611.54.1.el9_7.0.1 (Patch xfrm: esp: avoid in-place decrypt on shared skb frags), für Rocky 8 und 10 mit parallelen Builds. Aktivierungsschritte im verlinkten Artikel.

Worum es geht

Die Lücke sitzt im IPsec-Code des Kernels, konkret in den Modulen esp4 und esp6 aus dem XFRM-Subsystem. Ein lokaler unprivilegierter Account kann sie auslösen und Root-Rechte erlangen. Die "Fragnesia"-Variante (CVE-2026-46300) trifft den ESP-in-TCP-Pfad im selben Subsystem. Red Hat listet im Bulletin einen einzigen Mitigation-Block für das ganze Paket; die zwei Varianten unten decken Dirty Frag und Fragnesia gemeinsam ab.

ESP (Encapsulating Security Payload, RFC 4303) ist das verschlüsselnde Kernprotokoll von IPsec, XFRM das Kernel-Framework darunter, das IPsec-Policies und Security Associations verwaltet und Pakete in die Krypto-Module routet. ESP-in-TCP (RFC 8229) kapselt ESP in TCP, damit IPsec durch Firewalls läuft, die das native Protokoll blocken.

Eckdaten:

  • Red Hat-Public: 2026-05-07, Severity Important für alle im Bulletin gelisteten CVEs
  • Affected laut Red Hat: RHEL 8, 9 und 10 sowie OpenShift Container Platform 4
  • Codename im Bulletin: Dirty Frag, alternativ Copy Fail 2

Bin ich betroffen?

Auf RHEL und kompatiblen Distros (Rocky Linux, AlmaLinux, CentOS Stream, Oracle Linux) sind die ESP-Module Teil der Standard-Kernel-Builds. Prüfen, ob sie aktuell geladen sind:

$ lsmod | grep -E 'esp4|esp6'

Treffer heisst, ein Angriff ist möglich. Kein Treffer heisst nicht zwangsläufig sicher, weil die Module später noch dynamisch geladen werden können.

Mitigation Variante 1: ESP-Module sperren

Wer IPsec auf dem Host nicht nutzt, kann die Module über modprobe sperren. Site-to-Site-VPN, strongSwan, libreswan und vergleichbare Setups fallen aus. Für solche Hosts ist die zweite Variante besser.

Red Hat-Bulletin im Wortlaut:

$ printf 'install esp4 /bin/false\ninstall esp6 /bin/false\n' | sudo tee /etc/modprobe.d/dirtyfrag.conf
$ sudo rmmod esp4 esp6 2>/dev/null || true

Validierung:

$ lsmod | grep -E 'esp4|esp6'                  # leer
$ sudo modprobe -v esp4                        # "install /bin/false" und Fehler

Siehe auch https://docs.linuxfabrik.ch/base/system/kernel.html

Mitigation Variante 2: User-Namespaces abschalten

Variante zwei legt Red Hat als "No Impact to IPsec" vor: unprivilegierte User-Namespaces deaktivieren. Wortlaut aus dem Bulletin:

$ echo "user.max_user_namespaces=0" | sudo tee /etc/sysctl.d/dirtyfrag.conf
$ sudo sysctl --system

Validierung:

$ sysctl user.max_user_namespaces              # 0

Vorsicht: bricht alle Workloads, die unprivilegierte User-Namespaces brauchen. Insbesondere rootless Container (Podman als Non-Root, unprivileged LXC) und Bubblewrap-basierte Apps wie Flatpak.

Welche Mitigation passt?

  • VPN-Gateway oder anderer IPsec-Host: User-Namespaces abschalten. IPsec bleibt funktionsfähig.
  • Host mit rootless Containern, kein IPsec: ESP-Module sperren. Container-Stack bleibt funktionsfähig.
  • IPsec und rootless Container parallel: keine Mitigation ohne Funktionsverlust. Den Patch einspielen, sobald die Distro ihn ausliefert. Das Mantra "ein Server, eine Aufgabe" hilft für die Zukunft.
  • Reiner Application-Host ohne IPsec und ohne rootless Container: beide Mitigationen unkritisch, ESP-Sperre ist schneller rollbackbar.

Container-Hosts

ESP-Module gehören zum Host-Kernel, Container teilen den Kernel. Die Mitigation muss zwingend auf dem Host gesetzt werden. Eine container-seitige seccomp-/SELinux-/AppArmor-Policy reicht nicht.

Patch einspielen

Sobald die Distro den Fix ausliefert:

$ sudo dnf check-update kernel
$ sudo dnf upgrade kernel
$ sudo systemctl reboot

Danach die Mitigation zurücknehmen:

# Variante 1
$ sudo rm /etc/modprobe.d/dirtyfrag.conf
# Variante 2
$ sudo rm /etc/sysctl.d/dirtyfrag.conf
$ sudo sysctl --system

Rocky-Linux-Nutzer können den Hot-Fix-Kernel bereits über das security-Repository einspielen, bevor das reguläre BaseOS-Errata-Update folgt.

Wir helfen dir

Brauchst du Unterstützung beim Patchen oder Härten deiner Linux-Server? Schau dir doch mal unsere Service & Support-Modelle an und melde dich bei uns.

Vorheriger Beitrag Nächster Beitrag

DE · EN