Kaum hatte ich nach Copy Fail alle meine Kisten durchgepatcht und mir gedacht „so, das Thema ist durch”, kam Mitte Mai schon die nächste Hiobsbotschaft: Dirty Frag. Wieder eine lokale Rechteausweitung, und wie bei Copy Fail lag der Exploit binnen 24 Stunden auf GitHub – diesmal aber gleich für zwei Lücken auf einmal. Mein Proxmox-Host lief noch auf einem Kernel von vor dem Fix, und genau das ist das Tückische: Bei einem Hypervisor mit einem Dutzend LXC-Containern teilen sich alle denselben Kernel. Eine Lücke im Host trifft jeden Container gleich mit.
Ich zeig dir genau die Schritte, die ich auf meinem Proxmox-Host gemacht habe – Check, Patch, und den Modul-Block für den Fall, dass der Reboot warten muss. Die Lücke betrifft aber jeden Linux-Server, nicht nur den Hypervisor im Heimnetz: gemieteter Root-Server, Cloud-VM, Webserver – das Vorgehen ist überall dasselbe.
Was ist Dirty Frag (CVE-2026-43284 & CVE-2026-43500)?
Dirty Frag ist keine einzelne Lücke, sondern eine Kette aus zwei kernelinternen Schwachstellen, die beide nach demselben Muster funktionieren: Ein unprivilegierter Prozess bringt den Kernel dazu, in den Page-Cache einer eigentlich nur lesbaren Datei zu schreiben. Da im Page-Cache auch ausführbare setuid-Binaries wie /usr/bin/su liegen, lässt sich darüber ein Weg zu root bauen, ohne die Datei auf der Platte überhaupt anzufassen.
Die beiden CVEs stecken in unterschiedlichen Kernel-Subsystemen, jeweils im In-Place-Entschlüsselungspfad:
- CVE-2026-43284 – der ESP/IPsec-Pfad über das
xfrm-Subsystem (esp4,esp6). Eingestuft mit CVSS 8.8 (HIGH), im Kernel seit einem Commit von Januar 2017. - CVE-2026-43500 – der RxRPC-Pfad (
rxrpc, das AF_RXRPC-Transportprotokoll, u. a. für AFS). CVSS 7.8 (HIGH), jünger – seit 2023 im Code.
Wichtig zur Einordnung: Dirty Frag ist nicht aus der Ferne ausnutzbar. Ein Angreifer braucht bereits lokalen Code-Zugriff. Bei mir wäre das typische Szenario ein aus dem Netz erreichbarer Container – etwa eine Nextcloud-Instanz: Wird die kompromittiert, fängt genau da die Angriffskette an. Gefährdet sind also vor allem Server mit mehreren Nutzern oder öffentlich erreichbaren Diensten. Die Lücke wurde am 7. Mai 2026 öffentlich – nachdem ein Dritter das Embargo gebrochen hatte – und am Tag darauf lag ein funktionierender Proof-of-Concept auf GitHub. Offizielle Details findest du im Ubuntu-Advisory zu Dirty Frag und in der Tenable-FAQ.
Wer den Vorgänger noch nicht abgearbeitet hat, sollte das parallel tun: Die Mechanik ähnelt der von Copy Fail (CVE-2026-31431), aber die Gegenmaßnahmen sind andere – dazu unten mehr.
Bist du betroffen?
Die ehrliche Kurzantwort: Wenn du seit 2017 einen Linux-Kernel fährst, der nicht in den letzten Wochen aktualisiert wurde, mit hoher Wahrscheinlichkeit ja. Praktisch jede in den letzten neun Jahren erschienene Distribution ist anfällig. Prüfen geht trotzdem schnell.
Zuerst der laufende Kernel:
uname -rDiese Versionsnummer allein reicht aber nicht als Beweis. Entscheidend ist, ob dein konkreter Distributions-Kernel die Fixes für beide CVEs schon enthält – und das siehst du nur am Paketstand. Auf Debian, Proxmox und Ubuntu:
dpkg -l 'linux-image*' 'proxmox-kernel*' 'pve-kernel*' 2>/dev/null | awk '/^ii/ {print $2, $3}'Auf RHEL-Derivaten (AlmaLinux, Rocky):
rpm -q kernel kernel-coreZum Schnell-Check, ob die verwundbaren Module gerade aktiv sind:
grep -E '^(esp4|esp6|rxrpc) ' /proc/modules || echo "Module aktuell nicht geladen"Sind die Module nicht geladen, sinkt das akute Risiko – geladen werden können sie aber jederzeit automatisch, sobald ein Dienst (etwa ein IPsec-VPN) sie anfordert. „Nicht geladen” ist also kein dauerhafter Schutz, sondern nur eine Momentaufnahme.
Die gepatchten Versionen im Überblick
Hier die Fixstände für die Systeme, die im Heimnetz und Homelab wirklich vorkommen. Liegt deine Version darunter, musst du updaten.
| Distribution | Linie | Gepatcht ab (mindestens) |
|---|---|---|
| Proxmox VE | proxmox-kernel-6.8 | 6.8.12-23-pve |
| Proxmox VE | proxmox-kernel-6.14 | 6.14.11-8-pve |
| Proxmox VE | proxmox-kernel-6.17 | 6.17.13-7-pve |
| Debian 12 (Bookworm) | linux-6.1 | 6.1.170-3 |
| Debian 13 (Trixie) | linux-6.12 | 6.12.86-1 |
| Ubuntu 22.04 LTS | linux | 5.15.0-181.191 |
| Ubuntu 24.04 LTS | linux | 6.8.0-124.124 |
| Ubuntu 25.10 | linux | 6.17.0-35.35 |
| Ubuntu 26.04 LTS | linux | 7.0.0-22.22 |
| AlmaLinux 9 | kernel | 5.14.0-611.54.3.el9_7 |
Die vollständigen Listen für alle Punktversionen und Cloud-Kernel stehen im Proxmox-Forum-Thread, im Ubuntu-Advisory und in der AlmaLinux-Mitteilung. Achte darauf, dass diese Stände den Dirty-Frag-Fix abdecken – die später entdeckte Schwester-Lücke Fragnesia (CVE-2026-46300) im selben ESP-Subsystem verlangt teils noch neuere Kernel. Verlass dich also auf das Advisory deiner Distribution, nicht auf „irgendein Update von letzter Woche”.
Patchen: der saubere Weg
In den meisten Fällen ist die Lösung erfreulich unspektakulär – Update einspielen, neu starten, fertig. Der Reboot ist hier nicht optional: Ein Kernel-Fix greift erst, wenn der neue Kernel auch wirklich läuft.
Debian / Ubuntu / Proxmox:
sudo apt update
sudo apt full-upgrade
sudo rebootNach dem Neustart prüfst du mit uname -r, ob der neue Kernel aktiv ist. Auf Proxmox lohnt der genauere Blick, gerade auf ZFS-/UEFI-Systemen, wo der gebootete Kernel nicht immer der zuletzt installierte ist:
pveversion -v
proxmox-boot-tool statusAlmaLinux / Rocky / Fedora:
sudo dnf update 'kernel*'
sudo rebootMein Admin-Tipp für Cluster: Wenn du mehrere Proxmox-Nodes betreibst, reboote nacheinander und geplant, nicht alle auf einmal. Ein halb gepatchter Cluster kann beim HA-Failover oder bei geteiltem Storage zickig werden. Migriere die VMs auf einen bereits gepatchten Node, starte den freien neu, und arbeite dich so durch – Quorum bleibt erhalten, kein Dienst fällt aus.
Container nicht vergessen – aber richtig
Ein Punkt, den viele übersehen: LXC-Container haben keinen eigenen Kernel. Sie nutzen den des Hosts. Du musst sie also nicht einzeln patchen – sobald der Proxmox-Host neu gebootet hat, sind alle LXC-Container mit abgesichert. Anders bei KVM-/QEMU-VMs: Die bringen ihren eigenen Kernel mit und brauchen jede für sich ein Update plus Reboot. Ich hab mir anfangs die Mühe gemacht, in jeden LXC zu sshen und apt zu starten – komplett umsonst, der Container-Kernel ist nur eine Anzeige des Host-Kernels.
Workaround, wenn du nicht sofort neu starten kannst
Manchmal geht ein Reboot gerade nicht – ein laufender Backup-Job, ein Dienst mit langer Uptime-Anforderung, ein Wartungsfenster erst nächste Woche. Für diese Lücke gibt es eine brauchbare Mitigation: Du blockierst die verwundbaren Module, sofern du sie nicht brauchst.
Prüfe zuerst, ob IPsec oder AFS überhaupt im Einsatz sind:
ip xfrm state 2>/dev/null
systemctl status strongswan 2>/dev/null || true
mount | grep -i afs || trueKommt da nichts Relevantes zurück, kannst du esp4, esp6 und rxrpc sperren. Wichtig dabei: install <modul> /bin/false ist robuster als ein simples blacklist, weil es auch das explizite Nachladen per modprobe verhindert, nicht nur das automatische:
printf '%s\n' \
'install esp4 /bin/false' \
'install esp6 /bin/false' \
'install rxrpc /bin/false' \
| sudo tee /etc/modprobe.d/dirtyfrag.conf
for m in esp4 esp6 rxrpc; do
sudo rmmod "$m" 2>/dev/null
done
sudo update-initramfs -u -k allAuf RHEL-Derivaten ersetzt du den letzten Befehl durch sudo dracut -f, damit die Sperre auch im initramfs persistent ist.
Achtung – einmalig und ernst gemeint: Diese Mitigation ist ein Notnagel, kein Ersatz für den Patch. Sie deaktiviert IPsec. Brauchst du das VPN auf dem Host, ist Blockieren keine Option – dann führt kein Weg am Kernel-Update vorbei. Und nach dem Patchen die Sperre wieder entfernen (sudo rm /etc/modprobe.d/dirtyfrag.conf plus initramfs neu bauen), sonst wunderst du dich später, warum IPsec nicht mehr startet.
Wer auf eine kommerzielle Livepatch-Lösung setzt (Canonical Livepatch, KernelCare), bekam die Fixes teils schon innerhalb von 24 Stunden nach Disclosure ohne Reboot – prüfen kannst du das mit canonical-livepatch status --verbose bzw. kcarectl --patch-info.
Fazit
Dirty Frag ist kein Drama, das dich nachts wachhalten muss – aber eine Lücke, die du diese Woche abarbeiten solltest, wenn auf deinen Linux-Hosts mehr als nur du selbst Zugriff hat. Der Aufwand ist gering: apt full-upgrade plus geplanter Reboot, auf Proxmox node-für-node. Spielst du IPsec auf dem Host nicht, hast du mit dem Modul-Block sogar eine saubere Brücke bis zum nächsten Wartungsfenster.
Mein konkreter Rat: Erst den Host-Kernel von Proxmox patchen (deckt alle LXC mit ab), dann die KVM-VMs einzeln, und am Ende mit proxmox-boot-tool status kontrollieren, dass auch wirklich der neue Kernel läuft. Wer Copy Fail und die kurz darauf folgende ptrace-Lücke ssh-keysign-pwn (CVE-2026-46333) noch offen hat, erledigt alle drei im selben Wartungsfenster.
Häufige Fragen
Muss ich Dirty Frag patchen, wenn auf meinem Server nur ich Zugriff habe? ▾
Das Risiko sinkt deutlich, weil die Lücke lokalen Zugriff voraussetzt – aber „nur ich” stimmt selten ganz. Jeder öffentlich erreichbare Dienst (Webserver, Nextcloud, ein Spieleserver) ist ein potenzieller Startpunkt, falls er kompromittiert wird. Auf einem reinen Einzelnutzer-Rechner ohne Netzwerkdienste kannst du das Update normal im nächsten Zyklus mitnehmen; auf einem Server mit erreichbaren Diensten solltest du zeitnah patchen.
Kann ich den Reboot mit kexec abkürzen? ▾
Ja, kexec lädt einen neuen Kernel direkt aus dem laufenden System heraus und überspringt den BIOS-/UEFI-Durchlauf – auf einem Server mit langsamem Hardware-POST spart das spürbar Zeit. Der Haken: Es ist kein vollwertiger Kaltstart, manche Treiber und FW-Zustände werden nicht sauber neu initialisiert, und auf Proxmox kann es mit ZFS/Boot-Tool zicken. Für einen reinen VM-Host mit knappem Wartungsfenster eine Option, für Produktivsysteme mit kritischer Hardware bleibe ich beim normalen Reboot.
Muss ich privilegierte und unprivilegierte LXC unterschiedlich behandeln? ▾
Für den Kernel-Fix selbst nein – beide nutzen den Host-Kernel, ein Host-Reboot deckt beide ab. Der Unterschied liegt im Restrisiko: Aus einem privilegierten Container ist ein Ausbruch auf den Host generell leichter, weshalb du dort besonders zügig patchen solltest. Unprivilegierte Container sind durch das User-Namespace-Mapping ohnehin stärker isoliert – sicher macht sie aber erst der gepatchte Host-Kernel.
Was ist der Unterschied zwischen Dirty Frag, Copy Fail und Fragnesia? ▾
Alle drei sind lokale Rechteausweitungen im Linux-Kernel aus dem Frühjahr 2026, aber über verschiedene Subsysteme. Copy Fail (CVE-2026-31431) sitzt in der Krypto-API (algif_aead), Dirty Frag in IPsec/ESP und RxRPC, Fragnesia (CVE-2026-46300) ebenfalls im ESP-Subsystem. Der Stolperstein in der Praxis: Fragnesia verlangt teils höhere Fixstände als Dirty Frag – auf Proxmox etwa beginnt der Fragnesia-Fix erst bei 7.0.2-3-pve bzw. 6.17.13-8-pve, also eine Punktversion über dem Dirty-Frag-Stand. Ein Kernel, der Dirty Frag schließt, ist also nicht automatisch gegen Fragnesia dicht.
Mein uname -r zeigt eine alte Version, aber das System ist aktuell – wie kann das sein? ▾
Das ist der Klassiker, wenn du nach dem Update nicht neu gestartet hast. Das neue Kernel-Paket ist installiert, aber es läuft noch der alte. Nach dem Reboot zeigt uname -r die neue Version. Auf Proxmox mit ZFS/UEFI prüfst du zusätzlich mit proxmox-boot-tool status, welcher Kernel tatsächlich gebootet wurde – dort kann der zuletzt installierte von dem abweichen, der startet.