--- title: "Kernel-Lücke 'Dirty Frag' (CVE-2026-43284)" url: 'https://www.linuxfabrik.ch/de/blog/kernel-luecke-dirty-frag' markdown: 'https://www.linuxfabrik.ch/de/blog/kernel-luecke-dirty-frag.md' lang: de date: '2026-05-07' description: 'Linux-Kernel-Lücke Dirty Frag (CVE-2026-43284) im IPsec-Code betrifft RHEL und Derivate: Privilege Escalation. Wie man patcht und sich bis dahin schützt.' taxonomy: category: - blog tag: - linux - security archives_month: - may_2026 archives_year: - '2026' --- [ Home ](https://www.linuxfabrik.ch/de) [ Blog ](https://www.linuxfabrik.ch/de/blog) Kernel-Lücke 'Dirty Frag' (CVE-2026-43284) Red Hat hat das Bulletin [RHSB-2026-003 "Dirty Frag"](https://access.redhat.com/security/vulnerabilities/RHSB-2026-003) 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](https://www.linuxfabrik.ch/de/blog/rocky-linux-security-repo) 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](https://www.linuxfabrik.ch/de/blog/rocky-linux-security-repo) 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](https://www.linuxfabrik.ch/de/leistungen/service-support) an und melde dich [bei uns](https://www.linuxfabrik.ch/de/kontakt). [ Vorheriger Beitrag](https://www.linuxfabrik.ch/de/blog/kernel-luecke-copy-fail) [Nächster Beitrag ](https://www.linuxfabrik.ch/de/blog/rocky-linux-security-repo) #### Tags [ansible](https://www.linuxfabrik.ch/de/blog/tag:ansible) [checklistfabrik](https://www.linuxfabrik.ch/de/blog/tag:checklistfabrik) [cloud](https://www.linuxfabrik.ch/de/blog/tag:cloud) [datacenter](https://www.linuxfabrik.ch/de/blog/tag:datacenter) [event](https://www.linuxfabrik.ch/de/blog/tag:event) [firewallfabrik](https://www.linuxfabrik.ch/de/blog/tag:firewallfabrik) [graylog](https://www.linuxfabrik.ch/de/blog/tag:graylog) [icinga](https://www.linuxfabrik.ch/de/blog/tag:icinga) [lfops](https://www.linuxfabrik.ch/de/blog/tag:lfops) [linux](https://www.linuxfabrik.ch/de/blog/tag:linux) [monitoring-plugins](https://www.linuxfabrik.ch/de/blog/tag:monitoring-plugins) [news](https://www.linuxfabrik.ch/de/blog/tag:news) [nextcloud](https://www.linuxfabrik.ch/de/blog/tag:nextcloud) [security](https://www.linuxfabrik.ch/de/blog/tag:security) #### Archiv - [2026](https://www.linuxfabrik.ch/de/blog/archives_year:2026) - [2025](https://www.linuxfabrik.ch/de/blog/archives_year:2025) - [2024](https://www.linuxfabrik.ch/de/blog/archives_year:2024) - [2023](https://www.linuxfabrik.ch/de/blog/archives_year:2023) - [2022](https://www.linuxfabrik.ch/de/blog/archives_year:2022) - [2021](https://www.linuxfabrik.ch/de/blog/archives_year:2021) - [2020](https://www.linuxfabrik.ch/de/blog/archives_year:2020) #### Abonnements [ Atom](https://www.linuxfabrik.ch/de/blog.atom) [ RSS](https://www.linuxfabrik.ch/de/blog.rss) --- ## Navigation - Parent: [Blog](https://www.linuxfabrik.ch/de/blog.md) - Previous: [Rocky Linux Security-Repository](https://www.linuxfabrik.ch/de/blog/rocky-linux-security-repo.md) - Next: [Kernel-Lücke 'Copy Fail' (CVE-2026-31431)](https://www.linuxfabrik.ch/de/blog/kernel-luecke-copy-fail.md)