Dirty Frag: Neue Linux-Kernel-Lücke ermöglicht Root-Zugriff

Am 7. Mai 2026 sind zwei eng verwandte Linux-Kernel-Lücken öffentlich geworden, die gemeinsam unter dem Namen „Dirty Frag“ kursieren: CVE-2026-43284 und CVE-2026-43500. Ihre Kombination erlaubt lokalen Nutzern eine Privilegieneskalation auf Root – und in Container-Setups potenziell einen Ausbruch aus dem Container. Funktionierende Proof-of-Concept-Exploits zirkulieren bereits, ein generischer Container-Escape ist laut Forschern technisch denkbar, aber bisher nicht öffentlich.

Was Dirty Frag technisch ausnutzt

Die beiden Lücken liegen in zwei sehr unterschiedlichen Subsystemen des Linux-Kernels, lassen sich aber zu einer Kette verbinden:

  • CVE-2026-43284 (ESP/XFRM): Im IPsec-/XFRM-Pfad fehlt eine Ownership-Prüfung beim sogenannten „in-place decrypt on shared skb frags“. Wer ein eigenes User-Namespace aufmachen darf, kann gemeinsam genutzte Speicherfragmente des Page-Cache überschreiben, die eigentlich kernelseitig kontrolliert werden.
  • CVE-2026-43500 (RXRPC): Im RXRPC-Subsystem (AFS-Filesystem-Protokoll, in vielen Distributionen standardmäßig aktiv) lassen sich Bearbeitungsschritte des Netzwerkprotokolls so verschachteln, dass dieselben Fragmente erneut beschrieben werden, während sie noch in Bearbeitung sind.
  • Die Kombination: Beide Bugs zusammen ergeben ein klassisches use-after-free auf shared skb fragments – ein präzise gesteuertes Schreiben in privilegierte Kernel-Strukturen. Daher der Name in Anlehnung an „Dirty COW“.
Bootmeldungen des Linux-Kernels in der Konsole

Wer ist betroffen?

  • Distributionen mit aktivierten User-Namespaces für unprivilegierte Nutzer. Standardmäßig betrifft das Ubuntu, Debian, Fedora und viele Cloud-Images – alle, die Tools wie bwrap, podman --userns oder Flatpak ohne weitere Härtung unterstützen.
  • Systeme mit aktivem RXRPC-Modul. Ubuntu lädt das Modul auf vielen Installationen, weil es Teil des Standard-Kernels ist. Auf Debian, Fedora und Arch hängt es von der Distro-Kernel-Config ab.
  • Container-Hoster. Proxmox, Kubernetes-Nodes und LXC/LXD-Maschinen sind besonders relevant: Dort hat oft jeder unprivilegierte Mandant per Default Zugriff auf User-Namespaces.
  • Server mit klassischem Multi-User-Zugriff. Universitäten, Shared-Hosting, CI-Runner – überall, wo nicht-vertrauenswürdige Lokal-Logins existieren.

Privatgeräte mit nur einem Nutzer und ohne lokale Angreifer sind kein primäres Ziel – aber das Update ist trotzdem Pflichtprogramm, weil jeder zweite Bug, der Local-Root liefert, sich später mit Browser-Lücken oder anderen Sandbox-Escapes zur kompletten Kompromittierung kombinieren lässt.

Patches und Status der Distributionen

Die Upstream-Patches sind in den stable-Trees von 6.6, 6.12 und 6.18 gelandet. Der Roll-out in den Distributionen läuft seit dem 8. Mai:

  • Ubuntu: Updates für 22.04, 24.04 und 25.04 sind im updates-Repo. Manche LTS-Kernel-Varianten benötigen einen zweiten Update-Schwung – kernel-pakete bis HWE-Release prüfen.
  • Debian: Bookworm und Trixie haben jeweils einen DSA-Sicherheitsupdate erhalten.
  • Fedora/RHEL: Fedora 41 und 42 sind aktuell, RHEL 9.x bekommt das Update gestaffelt. Erratum-Nummer prüfen.
  • Arch / CachyOS: Mit dem 6.18-stable-Tree bereits gepatcht. Ein sudo pacman -Syu und ein Reboot reichen.
  • Proxmox: Patch im pve-kernel verfügbar, Reboot der Hosts notwendig.

Schnellcheck: Bin ich betroffen?

Drei kurze Kommandos klären, ob das eigene System aktuell angreifbar ist:

# 1. Laufende Kernel-Version anzeigen
uname -r

# 2. Pruefen, ob das RXRPC-Modul geladen ist
lsmod | grep -E 'rxrpc|esp[46]'

# 3. Unprivilegierte User-Namespaces erlaubt?
cat /proc/sys/kernel/unprivileged_userns_clone 2>/dev/null
sysctl kernel.unprivileged_userns_clone

Liefert Punkt 3 eine 1 und Punkt 2 ein geladenes rxrpc-Modul, gehört dein System zur primären Risikogruppe. Updates jetzt einspielen und Kernel neu starten.

Kernel-Konfigurationswerkzeug make gconfig auf einem Linux-System

Temporäre Workarounds, falls Update unmöglich

Wenn ein sofortiger Reboot oder Kernel-Wechsel nicht möglich ist – etwa bei produktiven Hypervisoren – lassen sich beide Angriffsketten temporär entschärfen:

  • Unprivilegierte User-Namespaces deaktivieren: sudo sysctl kernel.unprivileged_userns_clone=0. Achtung – Flatpak, Podman im rootless-Mode und einige Browser-Sandboxes verlieren damit ihre Sandbox-Layer.
  • RXRPC-Modul blacklisten: echo "blacklist rxrpc" | sudo tee /etc/modprobe.d/rxrpc.conf und Reboot. Nur problematisch, wenn du AFS-Dateisysteme nutzt – sonst völlig schmerzfrei.
  • ESP-Module entladen: sudo modprobe -r esp4 esp6 – das deaktiviert IPsec-Verschlüsselung. Nur sinnvoll auf Systemen ohne IPsec-VPN-Anbindung.

Fazit

Dirty Frag ist keine Remote-Lücke und kein Internet-Notfall – aber überall, wo lokale Mehrnutzerszenarien existieren oder Container nicht vollständig privilegiert getrennt sind, gehört das Kernel-Update oben auf die To-do-Liste dieser Woche. Privatnutzer brauchen keine Panik, aber dürfen die regulären Updates nicht aufschieben. Wer auf CVE-2026-35535 in sudo noch nicht reagiert hat, sollte beide Themen in einem Rutsch erledigen.


Bildquelle: Wikimedia Commons (CC BY-SA 4.0 / GPL).

Schreibe einen Kommentar

Nach oben scrollen