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“.

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 --usernsoder 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 -Syuund 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_cloneLiefert 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.

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.confund 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).


