Security 17.05.2026 Aktualisiert: 18.05.2026

Dirty Frag CVE-2026-43284/CVE-2026-43500: Linux prüfen und patchen

Dirty Frag betrifft Linux-Kernel, Plesk-, Proxmox- und Container-Hosts. Betroffene Versionen, Mitigation, Vendor-Fixes und Reboot-Prüfung.

Stand: 18.05.2026, 15:52 Uhr CEST. Dirty Frag ist nicht mehr nur “PoC ohne Patches”. Debian, AlmaLinux, CloudLinux und Proxmox haben konkrete Fixstände; Rocky nutzt für schnelle Fixes einen optionalen Security-Repo-Pfad; AWS meldet Amazon-Linux-Updates in seinem Sammelbulletin. Entscheidend ist trotzdem nicht uname -r allein, sondern ob dein konkreter Vendor-Kernel die Fixes für CVE-2026-43284 und CVE-2026-43500 enthält oder ob die betroffenen Module wirksam blockiert sind.

Kurzfassung

Worum es geht: Dirty Frag ist eine lokale Rechteausweitung im Linux-Kernel. Der öffentliche Exploit kombiniert zwei Page-Cache-Write-Bugs: CVE-2026-43284 im xfrm-/ESP-Pfad und CVE-2026-43500 im rxrpc-Pfad.
Remote allein ausnutzbar: Nein. Ein Angreifer braucht lokale Code-Ausführung, zum Beispiel einen Shell-Account, eine kompromittierte Webanwendung, einen CI-Job, Plugin-Code oder Code in einem Container.
Warum es trotzdem dringend ist: Auf Shared-Hosting-Systemen, Plesk-Servern, CI-Runnern, Container-Nodes und LXC-lastigen Proxmox-Hosts kann ein begrenzter lokaler Einstieg zu Root auf dem Host werden.
Copy-Fail-Mitigation reicht nicht: Wer nach CVE-2026-31431 nur algif_aead blockiert hat, ist gegen Dirty Frag nicht automatisch geschützt. Dirty Frag nutzt esp4, esp6 und rxrpc.
Betroffen: Viele Linux-Kernel mit nutzbarem ESP/IPsec- oder RxRPC-Codepfad. Der genaue Status hängt vom Vendor-Kernel, Backports, Kernel-Flavour, geladenen Modulen und lokalen Policies ab.
Saubere Lösung: Vendor-Kernel aktualisieren, anschließend in den gefixten Kernel booten oder einen passenden Livepatch nachweisen. Danach prüfen, ob die temporäre Modul-Blocklist noch gebraucht wird.
Zwischenlösung: esp4, esp6 und rxrpc blockieren und bereits geladene Module entladen. Das kann IPsec, strongSwan, Libreswan, AFS oder Spezial-Setups brechen.
Nicht machen: Den öffentlichen PoC nicht auf Produktivsystemen starten. Er kann Page-Cache-Seiten von Dateien wie /usr/bin/su oder /etc/passwd verändern. Das ist kein harmloser “Scanner”.

Was ist Dirty Frag?

Dirty Frag gehört zur gleichen größeren Fehlerklasse wie Dirty Pipe und Copy Fail: Ein unprivilegierter Prozess bekommt es hin, Kernel-Code zu einer Schreiboperation auf Speicher zu bringen, der eigentlich nur als gelesene Datei im Page Cache vorliegt.

Der Page Cache ist der Speicherbereich, in dem Linux Dateiinhalte zwischenspeichert. Wenn ein Prozess /usr/bin/su oder /etc/passwd nur lesend öffnet, darf er diese Datei nicht verändern. Wenn aber ein Kernel-Pfad intern auf genau diese Page-Cache-Seite schreibt, sieht der nächste Leser plötzlich die manipulierte Kopie aus dem RAM. Die Datei auf der Platte muss dabei nicht verändert worden sein.

Dirty Frag nutzt dafür nicht AF_ALG wie Copy Fail. Der öffentliche Exploit nutzt zwei andere Wege:

CVE	Teil der Kette	Kernel-Bereich	Praktische Rolle
CVE-2026-43284	xfrm-ESP Page-Cache Write	`esp4`, `esp6`, IPsec/ESP, `xfrm`	Starker 4-Byte-Write über ESP-In-Place-Decrypt. Braucht in typischen Setups einen Weg zu `CAP_NET_ADMIN`, oft über unprivileged user namespaces.
CVE-2026-43500	RxRPC Page-Cache Write	`rxrpc` / AF_RXRPC	Anderer Write-Pfad über RxRPC. Deckt Umgebungen ab, in denen der ESP-Weg durch User-Namespace-Policies blockiert ist, aber `rxrpc` verfügbar ist.

Die Kombination ist der unangenehme Teil. Wenn eine Umgebung den ESP-Pfad blockiert, kann der RxRPC-Pfad relevant werden. Wenn rxrpc gar nicht vorhanden ist, kann der ESP-Pfad reichen. Genau deshalb ist “ein Modul ist nicht geladen” nur ein Teil der Prüfung.

Wie funktioniert der Exploit technisch?

Die kurze Version: Dirty Frag schreibt nicht “magisch” auf eine Datei. Der Exploit bringt den Kernel dazu, auf eine Page-Cache-Seite zu schreiben, die aus Sicht des Userspace nur gelesen werden darf. Genau dieser Unterschied macht die Lücke so tückisch. Auf der Platte kann die Datei unverändert bleiben, während Prozesse im selben Moment eine manipulierte RAM-Kopie sehen.

Der ESP-Teil, CVE-2026-43284, nutzt den xfrm-/IPsec-Pfad. Der Kernel verarbeitet Netzwerkpakete intern mit Fragmenten, die über skb_frag_t auf Speicherseiten zeigen. In einem normalen Netzwerkpfad ist das Paketpuffer. Im angreifbaren Fall kann diese Referenz aber auf eine Page-Cache-Seite einer Datei zeigen. Der ESP-Code entschlüsselt dann “in place”, also direkt in diesen Speicherbereich hinein. Was aus Sicht des Netzwerkcodes ein Paketfragment ist, ist praktisch die gecachte Datei-Seite. Das Ergebnis ist ein kontrollierbarer kleiner Write in den Page Cache.

Warum taucht dabei ständig CAP_NET_ADMIN auf? Weil das Vorbereiten von XFRM-/ESP-Zuständen administrative Netzwerkrechte braucht. Auf vielen Distributionen kann ein unprivilegierter Benutzer über unprivileged user namespaces eine eigene Namespace-Welt bauen, in der er CAP_NET_ADMIN besitzt. Genau deshalb ist die User-Namespace-Policy für den ESP-Pfad so wichtig.

Der RxRPC-Teil, CVE-2026-43500, ist derselbe Fehlertyp in einem anderen Subsystem. Auch dort landet Kernel-Code auf einem Pfad, in dem ein Fragment, das auf eine Page-Cache-Seite zeigen kann, verändert wird. Der öffentliche Write-up beschreibt diesen Teil als zusätzliche Write-Primitive über RxRPC. Praktisch ist das relevant für Systeme, auf denen der ESP-Weg durch User-Namespace-Härtung blockiert ist, rxrpc aber verfügbar oder autoloadbar bleibt.

Aus diesen kleinen Writes wird Root, indem der Exploit nicht versucht, beliebig große Dateien sauber umzuschreiben. Er verändert gezielt wenige Bytes in einer sensiblen gecachten Datei, typischerweise in einem SUID-Programm oder in einer Authentifizierungsdatei. Danach reicht ein normaler Programmstart oder ein normaler Lesezugriff, damit der manipulierte Inhalt aus dem Page Cache verwendet wird.

Das erklärt auch zwei betriebliche Details:

Datei-Hashes können sauber aussehen, weil die Datei auf dem Storage nicht zwingend verändert wurde.
Nach einem Test oder Verdacht reicht “PoC beendet” nicht. Der Page Cache kann weiter kontaminiert sein, bis er geleert wird oder der Host rebootet.

Das ist bewusst keine Exploit-Anleitung. Für Betrieb und Patchplanung reicht der entscheidende Punkt: Dirty Frag ist ein Page-Cache-Write über Kernel-Netzwerkpfade, kein normaler Dateischreibzugriff und kein reines Modul-Status-Problem.

Warum Dirty Frag mehr ist als ein weiterer Kernel-CVE

Bei vielen Kernel-LPEs ist die erste Frage: Wie zuverlässig ist der Exploit? Dirty Frag ist aus Betriebssicht deshalb ernst zu nehmen, weil der veröffentlichte PoC kein wackeliges Timing-Fenster braucht. Die Forscherbeschreibung ordnet den Bug als deterministische Logiklücke ein. Wenn die Voraussetzungen passen, ist der Weg zu Root vergleichsweise direkt.

Das heißt nicht, dass jeder Server sofort aus dem Internet rootbar ist. Es heißt aber: Sobald ein Angreifer lokalen Code ausführen kann, wird die Grenze zwischen “eingeschränkter Benutzer” und “Root” dünn.

Typische Wege zu lokaler Code-Ausführung sind nicht exotisch:

kompromittierte WordPress-, TYPO3-, Shopware- oder Laravel-Anwendung
SSH-Zugang eines Kunden oder ehemaligen Dienstleisters
ein CI-Runner, der fremden Pull-Request-Code baut
ein Plesk- oder Shared-Hosting-System mit getrennten Systembenutzern
ein Container-Workload, der nicht vollständig vertrauenswürdig ist
ein LXC-Container auf einem Proxmox-Host
ein Cronjob oder Deployment-Script, das ein Angreifer verändern konnte

Auf einem reinen Single-User-Server ohne fremde Workloads ist das Risiko niedriger. Ignorieren würde ich es trotzdem nicht. Viele echte Angriffe beginnen nicht mit Root, sondern mit einem kleinen lokalen Fuß in der Tür.

Wer ist betroffen?

Eine einfache Aussage wie “Kernel kleiner als X ist betroffen” führt hier schnell in die Irre. Distributionen backporten Kernel-Fixes. Ein Debian-Kernel mit 6.1.x kann gefixt sein, obwohl ein unveränderter Upstream-6.1.x aus derselben Linie verwundbar wäre. Umgekehrt kann ein neu wirkender Vendor-Kernel noch offen sein, wenn der Backport fehlt.

Umgebung	Einschätzung	Worauf prüfen
Debian	Debian listet für CVE-2026-43284 und CVE-2026-43500 fixe Kernelstände in Bullseye Security, Bookworm, Trixie, Forky und Sid.	Installiertes Paket und laufenden Kernel prüfen. Bei Bullseye auf Security-Kernel achten, nicht nur auf die alte Base-Version.
Ubuntu	Canonical bewertet Dirty Frag als High und beschreibt alle Ubuntu-Releases in der Mitigation als betroffen. Die Ubuntu-CVE-Seiten führen viele Kernel-Flavours einzeln.	Ubuntu-CVE-Seiten pro Kernel-Flavour prüfen, Mitigation anwenden, falls noch kein bestätigter Kernel-Fix für den laufenden Kernel vorhanden ist.
RHEL / OpenShift	Red Hat führt Dirty Frag in einem Security Bulletin für RHEL 8, 9, 10 und OpenShift 4. Laut Red Hat betrifft CVE-2026-43500 Red-Hat-Produkte nicht, CVE-2026-43284 aber schon.	Red-Hat-Advisory, Errata und laufenden Kernel prüfen. Wenn IPsec gebraucht wird, Red-Hat-Alternative über User-Namespaces bewerten.
AlmaLinux	AlmaLinux 8, 9 und 10 sind für den ESP-Teil betroffen. Für AlmaLinux 9 und 10 ist der RxRPC-Teil nur relevant, wenn `kernel-modules-partner` installiert ist; AlmaLinux 8 baut `rxrpc` nicht.	Mindestens `kernel-4.18.0-553.123.2.el8_10`, `kernel-5.14.0-611.54.3.el9_7` oder `kernel-6.12.0-124.55.3.el10_1`, danach Reboot.
Rocky Linux	Rocky hat für Dirty Frag einen optionalen Security-Repo-Hotfix veröffentlicht. Rocky beschreibt den Kanal als temporäre Brücke; spätere Upstream-Kernel können Hotfixes wieder überschreiben. Der RxRPC-Teil betrifft praktisch nur Systeme mit `kernel-modules-partner` aus Devel.	`dnf --enablerepo=security update` prüfen, falls der beschleunigte Fix gebraucht wird. Danach später wieder gegen den normalen upstream-kompatiblen Kernelstand validieren.
CloudLinux	CL7 ist laut CloudLinux nicht betroffen. CL7 Hybrid, CL8, CL9 und CL10 sind betroffen, mit Kernel-Updates oder KernelCare-Livepatch-Pfaden.	CL7h/CL8: `kernel-4.18.0-553.123.2.lve...` oder neuer. CL9/CL10 folgen AlmaLinux-Kernelständen. KernelCare separat nachweisen.
Amazon Linux	AWS 2026-030 meldet verfügbare Amazon-Linux-Updates für die betroffenen Kerneltracks im Copy-Fail-/Dirty-Frag-Umfeld. Bottlerocket, ECS, EKS, EMR, Fargate und SageMaker haben eigene Rollout-Termine oder Image-Wechsel.	AWS-Bulletin, ALAS-Track und tatsächlichen Kernel- oder AMI-Stand prüfen.
Oracle Linux	Oracle führt eigene ELSA-Errata für RHCK- und UEK-Kernel. OL7/8/9/10 können je nach Kerneltyp unterschiedliche Advisory-Nummern haben.	Nicht nur “Oracle Linux 9” prüfen, sondern ob RHCK oder UEK läuft. `uname -r`, `rpm -q kernel kernel-uek` und Oracle-CVE-/ELSA-Seite abgleichen.
Fedora / Fedora CoreOS	Fedora CoreOS nennt konkrete gefixte Releases. Klassische Fedora-Systeme müssen über Kernel-Updates und Bodhi-/DNF-Status geprüft werden.	FCOS: mindestens die im Fedora-CoreOS-Hinweis genannten Releases. Fedora Workstation/Server: `dnf update 'kernel*'`, Reboot und laufenden Kernel prüfen.
SUSE / openSUSE / SUSE Virtualization	SUSE führt CVE-Seiten und mehrere Security Advisories. Für SLE 15 SP6 nennt SUSE ein wichtiges Kernel-Update mit Reboot-Pflicht. SUSE Virtualization nannte alle Versionen betroffen und empfiehlt die Modul-Blocklist als Workaround.	Produktgenaue SUSE-CVE-Seite prüfen. Nicht alle SUSE-Produkte haben denselben Status: “Released”, “In progress”, “Not affected” unterscheiden.
Plesk-Server	Plesk selbst ist nicht der Bug. Entscheidend ist der darunterliegende Linux-Kernel. Plesk-Server sind praktisch relevant, weil dort häufig viele getrennte Kunden- oder Website-Benutzer laufen.	OS-Vendor-Update, KernelCare falls vorhanden, Reboot-Status und Modul-Mitigation prüfen.
Proxmox VE	Proxmox führt Dirty Frag in PSA-2026-00019-1/-2. LXC-Container teilen den Host-Kernel, KVM-VMs haben eigene Guest-Kernel.	Gefixt sind je nach Linie `7.0.2-2-pve`, `6.17.13-7-pve`, `6.14.11-8-pve`, `6.8.12-23-pve` und der Bookworm-Backport `6.14.11-8~bpo12+1` oder neuer. Host rebooten, Gäste separat prüfen.
Docker, Kubernetes, CI-Runner	Besonders relevant, wenn fremder Code läuft. Container teilen den Host-Kernel.	Node-Kernel patchen, seccomp/AppArmor/SELinux-Policies prüfen, nicht nur Images aktualisieren.
Single-Tenant-Server ohne fremde Shells	Geringeres Risiko, aber nicht “nicht betroffen”. Eine kompromittierte Anwendung kann lokaler Code sein.	Normal priorisiert patchen, bei öffentlichem PoC aber nicht auf den nächsten Quartals-Wartungstermin schieben.

Was ist nicht betroffen oder deutlich entschärft?

Nicht betroffen oder praktisch entschärft sind Systeme, bei denen die verwundbaren Codepfade nicht nutzbar sind oder der Kernel den Vendor-Fix enthält. Das muss man sauber belegen.

Der laufende Kernel enthält die Backports für CVE-2026-43284 und CVE-2026-43500.
Ein Livepatch ist aktiv und weist die betroffenen CVEs für exakt den laufenden Kernel aus.
esp4, esp6 und rxrpc sind weder geladen noch autoloadbar.
Der Kernel enthält die betroffenen Module nicht.
Für den ESP-Pfad sind unprivileged user namespaces wirksam deaktiviert und rxrpc ist nicht verfügbar. Das ist eine Reduktion, aber kein Ersatz für einen Kernel-Fix in jeder Umgebung.
KVM-Gäste teilen den Host-Kernel nicht. Sie müssen trotzdem als eigene Linux-Systeme gepatcht werden.
AlmaLinux 8 ist laut AlmaLinux nicht vom RxRPC-Teil betroffen, bleibt aber für CVE-2026-43284 relevant.
CloudLinux 7 ist laut CloudLinux nicht betroffen. CloudLinux 7 Hybrid ist etwas anderes und betroffen.

Wichtig: Eine nicht geladene Moduldatei ist nicht dasselbe wie “sicher”. Wenn ein unprivilegierter Prozess ein Modul über einen passenden Socket oder Kernel-Pfad autoloaden kann, hilft “gerade nicht geladen” allein nicht. Deshalb nutzen die Vendor-Mitigationen install <modul> /bin/false statt nur blacklist.

Versionen und Fix-Grenzen

Für unveränderte Upstream-Kernel sind die NVD-Ranges eine gute Orientierung. Für Distributionen mit Backports sind sie nur ein Startpunkt.

CVE	Upstream-Fix-Kontext	Von NVD genannte verwundbare Upstream-Bereiche
CVE-2026-43284	Mainline-Fix `f4c50a4034e6`, später Stable-Backports.	`>= 4.11 < 5.10.255`, `>= 5.12 < 5.15.205`, `>= 5.16 < 6.1.171`, `>= 6.2 < 6.6.138`, `>= 6.7 < 6.12.87`, `>= 6.13 < 6.18.28`, `>= 7.0 < 7.0.5`.
CVE-2026-43500	Kernel.org/NVD verweisen unter anderem auf Fix-Commits wie `aa54b1d27fe0`.	`> 5.3 < 6.18.29`, `>= 6.19 < 7.0.6`, zusätzlich einzelne 5.3- und 7.1-rc-Builds.

Das wirkt sperrig, ist aber der Punkt: Bei produktiven Systemen zählt nicht die schöne Upstream-Tabelle, sondern die Antwort des eigenen Vendors. Debian, Ubuntu, Red Hat, SUSE, AlmaLinux, CloudLinux, Proxmox- und Cloud-Kernel tragen oft Patches zurück, ohne dass die Kernel-Hauptversion nach einer neuen Upstream-Stable-Version aussieht.

Bei Debian nennt der Security Tracker zum geprüften Stand unter anderem diese fixen Stände:

Debian-Zweig	Fix-Status laut Tracker
Bullseye Security	`linux` ab `5.10.251-5` und `linux-6.1` ab `6.1.170-3~deb11u1`
Bookworm	`6.1.170-3`, Bookworm Security `6.1.172-1`
Trixie	`6.12.86-1`, Trixie Security `6.12.88-1`
Forky	`7.0.4-1`
Sid	`7.0.7-1`

Bei AlmaLinux nennt der Hersteller diese Mindeststände:

AlmaLinux	Gepatchter Kernel laut AlmaLinux
AlmaLinux 8	`kernel-4.18.0-553.123.2.el8_10` oder neuer
AlmaLinux 9	`kernel-5.14.0-611.54.3.el9_7` oder neuer
AlmaLinux 10	`kernel-6.12.0-124.55.3.el10_1` oder neuer

Bei CloudLinux nennt der Hersteller unter anderem:

CloudLinux	Zielstand laut CloudLinux
CL7	nicht betroffen
CL7 Hybrid	`kernel-4.18.0-553.123.2.lve.el7h` oder neuer
CL8	`kernel-4.18.0-553.123.2.lve.el8` oder neuer
CL9	AlmaLinux-9-Kernelstand `5.14.0-611.54.3.el9_7` oder neuer
CL10	AlmaLinux-10-Kernelstand prüfen; AlmaLinux selbst nennt aktuell `6.12.0-124.55.3.el10_1` oder neuer

Ubuntu ist zum geprüften Stand schwieriger: Die offiziellen Ubuntu-CVE-Seiten führen viele Kernel-Source-Pakete und Flavours, zeigen aber für die aktiven Einträge überwiegend “Needs evaluation” statt einer klaren “fixed in version X”-Tabelle. Eine pauschale Ubuntu-Fixliste wäre deshalb unseriös. Für Ubuntu musst du den laufenden Flavour prüfen und dann die Ubuntu-CVE-Seite oder ein passendes USN gegen genau diesen Flavour halten.

Ubuntu-Prüffall	Worauf achten
Ubuntu 24.04 LTS / 26.04 LTS mit Standardkernel	`linux-image-generic`, HWE- oder OEM-Flavour prüfen. Nicht nur `linux-generic` ansehen, sondern den tatsächlich gebooteten `linux-image-*`.
Cloud-Images	`linux-aws`, `linux-azure`, `linux-gcp`, `linux-oracle`, `linux-kvm` und jeweilige `6.8`/`6.14`/`6.17`-Varianten getrennt prüfen.
Ubuntu Pro / ESM / FIPS / realtime	Fixstand über Ubuntu Pro, Livepatch-, FIPS- oder realtime-Kanal nachweisen. Diese Pakete laufen in eigenen Tracks.
Kernel mit Livepatch	`uname -r` bleibt gleich. Entscheidend ist, ob Livepatch die beiden CVEs für den laufenden Kernel nennt.

Für die praktische Ubuntu-Prüfung ist dieser Block nützlicher als eine erfundene Tabelle:

uname -r
dpkg -l 'linux-image*' 'linux-modules*' | awk '/^ii/ {print $2, $3}'
apt-cache policy linux-image-generic linux-image-generic-hwe-24.04 linux-image-aws linux-image-azure linux-image-gcp linux-image-oracle linux-image-kvm 2>/dev/null
canonical-livepatch status --verbose 2>/dev/null || true
pro status 2>/dev/null || true

Bei Proxmox VE gibt es konkrete Hinweise im Security Advisory PSA-2026-00019-2 und in den PVE-Kernel-Changelogs. Für die üblichen PVE-8- und PVE-9-Linien sind diese Mindeststände relevant:

Proxmox-Kernel-Linie	Dirty-Frag-Fixstand laut Proxmox	Hinweis
`proxmox-kernel-7.0`	`7.0.2-2-pve`	Laut Advisory bei Veröffentlichung für PVE/PMG/PDM im no-subscription-Repo verfügbar; Enterprise-Repo immer auf dem Node per `apt-cache policy` prüfen.
`proxmox-kernel-6.17`	`6.17.13-7-pve`	Trixie-basierte Produkte, darunter PVE 9.x.
`proxmox-kernel-6.14`	`6.14.11-8-pve`	Trixie-basierte Produkte.
`proxmox-kernel-6.8`	`6.8.12-23-pve`	Bookworm-basierte Produkte, darunter PVE 8.x.
`proxmox-kernel-6.14-bpo12`	`6.14.11-8~bpo12+1`	Bookworm-basierte Produkte mit Backport-Kernel.
alte `pve-kernel-6.2`-/`proxmox-kernel-6.5`-/`6.11`-Stände	nicht als Dirty-Frag-Fixstand behandeln	Auf aktuelle PVE-Kernel-Linie aktualisieren und rebooten.

Wichtig für Proxmox: Entscheidend ist nicht, welche Pakete irgendwo online existieren, sondern was dein Node aus seinem konfigurierten Repository sieht, installiert hat und nach dem Reboot wirklich bootet. Das gilt besonders für Umgebungen mit Enterprise-Repository und gepinnten Kernelständen.

pveversion -v
uname -r
dpkg -l 'proxmox-kernel*' 'pve-kernel*' | awk '/^ii/ {print $2, $3}'
apt-cache policy proxmox-kernel-6.8 proxmox-kernel-6.14 proxmox-kernel-6.17 proxmox-kernel-7.0 2>/dev/null

Auf ZFS-/UEFI-Proxmox-Nodes gehört außerdem der Bootloader-Check dazu:

proxmox-boot-tool status 2>/dev/null || true

Ein installiertes proxmox-kernel-6.8 in Version 6.8.12-23 bringt nichts, wenn der Host nach dem Wartungsfenster weiter mit 6.8.12-21-pve läuft.

Für Fragnesia gilt das nicht automatisch. Der Proxmox-Dirty-Frag-Fixstand 7.0.2-2-pve war laut späterem Forumstest noch für Fragnesia ausnutzbar. Proxmox hat dafür inzwischen ein eigenes Advisory PSA-2026-00020-1 veröffentlicht; die Fragnesia-Fixstände beginnen erst bei 7.0.2-3-pve, 6.17.13-8-pve, 6.14.11-9-pve, 6.8.12-24-pve und 6.14.11-9-bpo12-pve.

Weitere häufige Infrastruktur-Kernel sollte man separat behandeln:

Vendor / Plattform	Stand zum geprüften Zeitpunkt
Rocky Linux	Optionaler Security-Repo-Hotfix für Dirty Frag. Rocky weist ausdrücklich darauf hin, dass der Security-Repo-Kanal ein temporärer Notfallmechanismus ist und nicht wie normale Errata über `dnf update --security` gedacht ist. Der zweite Security-Repo-Kernel trägt den ESP-Fix weiter; den RxRPC-Fix will Rocky nicht dauerhaft unabhängig pflegen, weil der betroffene Partner-Modulpfad nicht Teil normaler Produktionsinstallationen sein sollte.
Amazon Linux	AWS-Bulletin 2026-030 meldet verfügbare Amazon-Linux-Updates für betroffene Kerneltracks. Bottlerocket-AMIs, ECS-optimierte AMIs und EKS-optimierte AMIs sollen laut AWS bis 19.05.2026 nachziehen; EMR und Fargate haben eigene Termine.
Oracle Linux	Oracle führt ELSA-Errata für RHCK und UEK. Die Advisory-Nummer hängt von Oracle-Linux-Version und Kerneltyp ab.
Fedora CoreOS	Fedora CoreOS nennt als gefixte Releases unter anderem `stable: 44.20260419.3.1`, `testing: 44.20260510.2.1` und `next: 44.20260510.1.1`.

Diese Tabellen sind bewusst nicht als vollständige Paketdatenbank gemeint. Sie zeigen, worauf man beim Patchen achten muss: ein einzelnes uname -r ohne Vendor-Kontext ist zu wenig.

Schnelle Prüfung auf einem Host

Zuerst brauchst du den laufenden Kernel:

uname -r
uname -a

Dann prüfst du, welche Kernelpakete installiert sind. Auf Debian, Ubuntu und Proxmox:

dpkg -l 'linux-image*' 'linux-modules*' 'proxmox-kernel*' 'pve-kernel*' 2>/dev/null | awk '/^ii/ {print $2, $3}'

Auf RHEL-, Alma-, Rocky-, CloudLinux- und Fedora-nahen Systemen:

rpm -q kernel kernel-core kernel-modules kernel-modules-extra kernel-modules-partner 2>/dev/null
uname -r

Auf SUSE:

zypper se -si 'kernel*'
uname -r

Danach geht es um die betroffenen Module. Geladen heißt nicht automatisch ausgenutzt, aber es ist ein klares Signal:

grep -E '^(esp4|esp6|rxrpc) ' /proc/modules || echo "esp4/esp6/rxrpc aktuell nicht geladen"

Prüfen, ob die Module grundsätzlich im laufenden Kernel vorhanden sind:

find "/lib/modules/$(uname -r)" -type f \( -name 'esp4.ko*' -o -name 'esp6.ko*' -o -name 'rxrpc.ko*' \) -print

Prüfen, ob eine Blocklist wirklich greift:

modprobe -n -v esp4
modprobe -n -v esp6
modprobe -n -v rxrpc

Wenn dort install esp4 /bin/false, install esp6 /bin/false und install rxrpc /bin/false erscheint, ist die typische Modul-Mitigation aktiv. Wenn insmod .../esp4.ko oder ähnliches erscheint, ist das Modul weiterhin ladbar.

Der Unterschied zu einer einfachen blacklist-Zeile ist wichtig: blacklist esp4 verhindert vor allem automatisches Laden über Alias-Auflösung. install esp4 /bin/false ersetzt den Ladebefehl selbst. Damit scheitert auch ein explizites modprobe esp4, solange diese modprobe-Konfiguration greift.

Für den ESP-Pfad ist außerdem relevant, ob unprivileged user namespaces offen sind:

sysctl user.max_user_namespaces 2>/dev/null
sysctl kernel.unprivileged_userns_clone 2>/dev/null

Das ist kein vollständiger Vulnerability-Scanner. Es hilft dir aber, die drei wichtigsten Fragen zu beantworten:

Welcher Kernel läuft wirklich?
Sind die betroffenen Module geladen oder ladbar?
Gibt es lokale Workloads, die aus einem begrenzten Benutzerkontext heraus angreifen könnten?

Updates einspielen

Die saubere Lösung ist ein Kernel-Update aus den Repositories deiner Distribution. Danach muss der Host entweder rebooten oder du musst einen passenden Livepatch nachweisen.

Debian, Ubuntu und Proxmox:

sudo apt update
sudo apt full-upgrade
sudo reboot
uname -r

Auf Proxmox zusätzlich sinnvoll:

pveversion -v
dpkg -l 'proxmox-kernel*' 'pve-kernel*' | awk '/^ii/ {print $2, $3}'
apt-cache policy proxmox-kernel-6.8 proxmox-kernel-6.14 proxmox-kernel-6.17 proxmox-kernel-7.0 2>/dev/null
proxmox-boot-tool status 2>/dev/null || true

RHEL, AlmaLinux, Rocky Linux, CloudLinux, Fedora:

sudo dnf clean metadata
sudo dnf update 'kernel*'
sudo reboot
uname -r

Bei älteren EL-Systemen kann noch yum statt dnf relevant sein.

SUSE und openSUSE:

sudo zypper refresh
sudo zypper patch
sudo reboot
uname -r

Bei Kernel-Livepatching zählt nicht, ob uname -r schön aussieht. uname -r bleibt beim Livepatching normalerweise gleich. Du brauchst den Nachweis aus dem Livepatch-Tool:

canonical-livepatch status --verbose 2>/dev/null || true
kpatch list 2>/dev/null || true
kcarectl --patch-info 2>/dev/null | grep -E 'CVE-2026-43284|CVE-2026-43500|dirtyfrag' || true

Wenn ein Livepatch nur CVE-2026-43284 nennt, CVE-2026-43500 aber offen bleibt, ist die Kette je nach System nicht vollständig entschärft. Bei Red Hat ist diese Differenz wichtig, weil Red Hat CVE-2026-43500 für die eigenen Produkte als nicht betroffen einordnet. Bei anderen Distributionen darf man das nicht übertragen.

Auf Debian und Ubuntu helfen zusätzlich needrestart oder checkrestart, um offene Reboot-Indizien zu sehen. Das ersetzt nicht die Kernelprüfung, fängt aber typische Wartungsfenster-Fehler ab:

needrestart -r l 2>/dev/null || true
checkrestart 2>/dev/null || true

Nach dem Reboot oder nach einer temporären Mitigation sollte ein kompakter Nachkontroll-Block laufen:

echo "Kernel: $(uname -r)"

grep -E '^(esp4|esp6|rxrpc) ' /proc/modules \
  && echo "WARNUNG: Mindestens ein Dirty-Frag-Modul ist noch geladen" \
  || echo "OK: esp4/esp6/rxrpc sind aktuell nicht geladen"

for module in esp4 esp6 rxrpc; do
  if modprobe -n -v "$module" 2>&1 | grep -q '/bin/false'; then
    echo "OK: $module ist per install /bin/false blockiert"
  else
    echo "INFO: $module ist nicht per install /bin/false blockiert oder im Kernel nicht vorhanden"
  fi
done

Temporäre Mitigation

Wenn ein Kernel-Fix noch nicht verfügbar ist oder ein sofortiger Reboot nicht geht, bleibt die Modul-Blocklist. Vorher musst du prüfen, ob der Host IPsec oder AFS/RxRPC wirklich nutzt.

IPsec-Indizien:

lsmod | grep -E '^(esp4|esp6)'
ip xfrm state 2>/dev/null
systemctl status strongswan 2>/dev/null || true
systemctl status ipsec 2>/dev/null || true
systemctl status libreswan 2>/dev/null || true

RxRPC/AFS-Indizien:

lsmod | grep -E '^rxrpc'
mount | grep -i afs || true

Wenn die Module nicht gebraucht werden, ist die typische Modul-Blockade:

printf '%s\n' \
  'install esp4 /bin/false' \
  'install esp6 /bin/false' \
  'install rxrpc /bin/false' \
  | sudo tee /etc/modprobe.d/dirtyfrag.conf

for module in esp4 esp6 rxrpc; do
  if grep -q "^${module} " /proc/modules; then
    sudo rmmod "$module" || echo "WARNUNG: $module konnte nicht entladen werden"
  fi
done

grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules \
  && echo "Mindestens ein Dirty-Frag-Modul ist noch geladen" \
  || echo "esp4/esp6/rxrpc sind aktuell nicht geladen"

Wenn du diese Mitigation über einen Reboot hinweg brauchst, muss sie auch im initramfs landen. Sonst kann ein früh geladenes Modul beim nächsten Boot wieder vor deiner späteren Userspace-Konfiguration aktiv sein.

Auf Debian und Ubuntu:

sudo update-initramfs -u -k all

Auf RHEL-, Alma-, Rocky-, CloudLinux-, Oracle- und Fedora-nahen Systemen:

sudo dracut -f

Das ist besonders relevant, wenn du noch keinen Kernel-Fix hast und die Modul-Mitigation als echte Übergangslösung betreibst.

Wenn IPsec auf einem Ubuntu-System gebraucht wird und esp4/esp6 deshalb nicht blockiert werden können, nennt Canonical als zusätzliche Härtung das Einschränken unprivilegierter User-Namespaces über AppArmor:

sudo sysctl kernel.apparmor_restrict_unprivileged_userns=1

Dieser Befehl ist flüchtig. Für Persistenz über Reboots hinweg:

printf '%s\n' 'kernel.apparmor_restrict_unprivileged_userns=1' \
  | sudo tee /etc/sysctl.d/99-dirtyfrag-userns.conf

sudo sysctl --system

Das ist keine universelle Drop-in-Mitigation. Rootless Container, Entwickler-Workflows und Desktop-Sandboxing können davon betroffen sein. Für Server mit fremden Workloads kann es trotzdem die bessere Übergangslösung sein als ein offener ESP-Pfad.

Bei anderen Distributionen solltest du die jeweilige Vendor-Anweisung nehmen. Wenn ein Modul früh im Boot geladen wird, ist ein vergleichbarer initramfs-Schritt relevant. Ein später gesetztes rmmod hilft dann nicht dauerhaft.

Die Blocklist zurücknehmen, nachdem ein gefixter Kernel installiert und aktiv ist:

sudo rm /etc/modprobe.d/dirtyfrag.conf

if command -v update-initramfs >/dev/null; then
  sudo update-initramfs -u -k all
fi

if command -v dracut >/dev/null; then
  sudo dracut -f
fi

Danach rebooten oder nach Vendor-Anweisung sicherstellen, dass die alte Blocklist nicht mehr aus einem initramfs oder Konfigurationsmanagement zurückkommt.

Was beim Patchen gern übersehen wird

Der häufigste Fehler ist ein installiertes Kernelpaket ohne Reboot. Das Paket liegt dann auf der Platte, aber der alte verwundbare Kernel läuft weiter.

Prüfe nach dem Wartungsfenster deshalb immer:

uname -r

und vergleiche den laufenden Kernel mit dem installierten Paketstand und dem Vendor-Tracker. Auf Systemen mit mehreren Kernel-Flavours reicht “apt upgrade war grün” nicht. Cloud-, HWE-, realtime-, pve-kernel-, kernel-lts-, FIPS- und Provider-Kernel haben oft eigene Paketnamen und eigene Fix-Zeitpunkte.

Der zweite Fehler ist eine unvollständige Mitigation. Nur esp4 und esp6 zu blocken lässt den RxRPC-Teil offen, wenn rxrpc vorhanden und ausnutzbar ist. Nur rxrpc zu blocken lässt den ESP-Teil offen. Nur algif_aead zu blocken war für Copy Fail relevant, aber nicht für Dirty Frag.

Der dritte Fehler ist eine blinde Blocklist auf IPsec-Systemen. esp4 und esp6 sind nicht dekorativ. Wer strongSwan-, Libreswan-, site-to-site-VPNs oder IPsec-basierte Kundentunnel betreibt, kann sich mit der Mitigation produktive Verbindungen abschießen. Red Hat nennt für Umgebungen, in denen IPsec weiterlaufen muss, als Alternative das Deaktivieren unprivilegierter User-Namespaces. Auch das hat Nebenwirkungen: rootless Container, Browser-Sandboxing, Flatpak und Entwickler-Workflows können betroffen sein.

Der vierte Fehler ist “Container aktualisiert, Host vergessen”. Ein Docker-, Kubernetes- oder LXC-Container bringt keinen eigenen Kernel mit. Der Host-Kernel entscheidet. Bei KVM-VMs ist es anders: Die VM hat ihren eigenen Guest-Kernel und muss separat gepatcht werden.

Der fünfte Fehler ist ein zu aggressives Aufräumen alter Kernel direkt nach dem Update. Gerade bei Proxmox, ZFS-Boot und Secure-Boot-Setups sollte ein bekannter, bootfähiger Fallback-Kernel erhalten bleiben, bis der neue Kernel einmal sauber gebootet hat und Netzwerk, Storage, Cluster und Backups geprüft sind.

Der sechste Fehler ist fehlende Reihenfolge im Cluster. Kubernetes-Nodes werden gedraint, Proxmox-HA-Workloads migriert oder bewusst gestoppt, CI-Runner aus der Queue genommen. Ein Kernelupdate ist kein normales Userland-Paketupdate. Der Reboot ist Teil des Fixes.

Page Cache nach Test oder Verdacht

Der öffentliche Dirty-Frag-PoC kann Page-Cache-Seiten von sensiblen Dateien verändern. Die Forscher nennen selbst, dass der Page Cache nach dem Exploit “kontaminiert” sein kann und durch Drop-Caches oder Reboot bereinigt werden soll.

Für autorisierte Tests auf einem isolierten Lab-System reicht danach:

sync
echo 3 | sudo tee /proc/sys/vm/drop_caches >/dev/null

Auf einem produktiven System mit Verdacht auf echte Ausnutzung ist das keine vollständige Incident Response. Wenn jemand über Dirty Frag Root bekommen hat, kann er danach persistente Änderungen vorgenommen, Logs manipuliert oder Secrets gelesen haben. Dann geht es nicht mehr nur um Page Cache. Dann gehören mindestens Isolierung, Log- und EDR-Prüfung, Secret-Rotation und je nach System ein sauberer Rebuild auf die Liste.

Datei-Hashes allein sind hier nur begrenzt hilfreich. Der ursprüngliche Trick ist ja gerade, dass die Datei auf der Platte sauber aussehen kann, während die im RAM gelesene Kopie manipuliert ist.

Einordnung für Plesk, Proxmox und Hosting

Für Plesk-Server ist Dirty Frag besonders unangenehm, weil Plesk-Hosts oft genau die Mischung haben, die lokale LPEs wertvoll macht: mehrere Kunden, mehrere Systembenutzer, Cronjobs, PHP-FPM-Pools, Webanwendungen, Backups, Deployment-Scripte und manchmal Shell-Zugänge. Plesk selbst patcht hier nicht den Kernel. Du musst den darunterliegenden OS-Kernel patchen oder livepatchen.

Bei Proxmox ist die Trennung wichtig:

Proxmox-Host: Der Host-Kernel muss gefixt sein. Hooks, Backup-Scripte, Admin-Shells und Automatisierung laufen nahe am Host.
LXC-Container: LXC teilt den Host-Kernel. Ein verwundbarer Host-Kernel ist deshalb direkt relevant, auch wenn der Container selbst ein anderes Userspace-System zeigt.
KVM-VMs: KVM-Gäste haben eigene Kernel. Der Gast muss separat gepatcht werden. Ein Exploit im Gast ist nicht automatisch ein Exploit im Host.
Cluster: Reboots brauchen Planung. Ein halb gepatchter Cluster ist besser als gar nichts, aber dokumentiere genau, welcher Node schon mit welchem Kernel läuft.

Für Hoster, Agenturen und MSPs ist die Priorisierung recht klar: Systeme mit fremdem Code zuerst. Dazu gehören Shared Hosting, Build-Server, GitLab Runner, Kubernetes-Nodes, Docker-Hosts mit Kundenworkloads und Proxmox-Hosts mit LXC-Containern, die nicht vollständig unter eigener Kontrolle stehen.

Nebenbaustelle: Fragnesia nicht übersehen

Nach Dirty Frag wurde mit Fragnesia, CVE-2026-46300, eine weitere LPE in derselben XFRM-/ESP-Nähe öffentlich. Das ist nicht derselbe CVE und nicht der Kern dieses Artikels. Für Patchplanung ist es aber relevant, weil einige Vendor-Advisories die Themen inzwischen gemeinsam behandeln.

Praktisch heißt das: Wenn du jetzt Wartungsfenster für Dirty Frag planst, prüfe den kompletten Kernel-Advisory-Stand deines Vendors und nicht nur zwei CVE-Nummern aus einem Blogpost. Sonst rebootest du heute für Dirty Frag und morgen noch einmal für eine eng verwandte Kernel-Lücke. Ebenfalls im Mai erschien ssh-keysign-pwn (CVE-2026-46333) mit einem ptrace-basierten Angriffspfad zum lokalen Lesen root-eigener Dateien – ein anderes Angriffsmuster, aber für dieselben Systeme relevant und denselben Kernel-Fix-Nachweis wert.

Wie wir damit umgehen würden

Bei einem produktiven Kunden-Setup wäre die Reihenfolge pragmatisch:

Hostliste aus Inventar, Monitoring, Proxmox, Cloud und Plesk ziehen.
Systeme nach Risiko sortieren: Shared Hosting, Container, CI, Shell-Zugänge, Multi-Tenant zuerst.
Pro Host laufenden Kernel, installierte Kernelpakete und betroffene Module prüfen.
Vendor-Fixes gegen Debian/Ubuntu/Red Hat/SUSE/Alma/CloudLinux/Proxmox-Paketstand abgleichen.
Wenn kein Fix oder kein sofortiger Reboot möglich ist: Modul-Mitigation mit IPsec-/AFS-Prüfung.
Reboot- oder Livepatch-Nachweis dokumentieren.
Nachkontrolle: laufender Kernel, Modulstatus, Monitoring und offene Hosts.
Bei Verdacht auf Ausnutzung nicht nur Cache leeren, sondern Incident-Pfad starten.

Wenn du nicht sicher bist, ob deine Server wirklich gefixt sind, ist ein kurzer Security- und Kernel-Check sinnvoller als blindes Patchen nach Bauchgefühl. Gerade bei Plesk-, Proxmox-, Container- und VPN-Umgebungen ist die Frage nicht nur “Update ja/nein”, sondern “welcher Host kann wann rebooten, welche Dienste brechen durch die Mitigation, und wie belegen wir danach den Zustand?”

Update-Log

2026-04-29: Der RxRPC-Teil wurde laut Forscher-Timeline an security@kernel.org gemeldet und ein Patch an die Netdev-Liste geschickt.
2026-04-30: Der xfrm-ESP-Teil wurde gemeldet; erste Patch-Vorschläge für ESP wurden öffentlich diskutiert.
2026-05-07: Dirty Frag wurde nach gebrochenem Embargo öffentlich gemacht. Der PoC und die technische Beschreibung erschienen im GitHub-Repository von Hyunwoo Kim.
2026-05-08: CVE-2026-43284 wurde zugewiesen. Der ESP-Fix f4c50a4034e6 wurde in Mainline aufgenommen. Canonical, AlmaLinux, CloudLinux und andere veröffentlichten erste Mitigations- und Patch-Hinweise.
2026-05-11: CVE-2026-43500 wurde in Ubuntu/NVD sichtbar. Mehrere Vendor-Tracker führten beide CVEs getrennt.
2026-05-13 bis 2026-05-14: SUSE veröffentlichte weitere Kernel-Advisories, darunter Updates für SLE-Varianten. NVD aktualisierte Referenzen und Ranges.
2026-05-14: Red Hat aktualisierte das Dirty-Frag-Bulletin und führt inzwischen auch die verwandte Fragnesia-Variante CVE-2026-46300 in derselben Advisory-Familie.
2026-05-17: Artikel angelegt. Vendor-Stände und Versionstabellen gegen die öffentlich verfügbaren Tracker und Advisories geprüft.
2026-05-17: Proxmox-Kernelstände aus den offiziellen PVE-Changelogs ergänzt: proxmox-kernel-6.8 ab 6.8.12-23, proxmox-kernel-6.14 ab 6.14.11-8~bpo12+1. Ubuntu-Abschnitt präzisiert, weil die Ubuntu-CVE-Seiten noch keine klare Fixed-Version-Tabelle liefern.
2026-05-17: Mitigation-Abschnitt nachgeschärft: install ... /bin/false gegenüber blacklist erklärt, dracut -f für EL-nahe Systeme ergänzt, AppArmor-User-Namespace-Sysctl persistent gemacht und ein Nachkontroll-Block ergänzt. Rocky Linux, Amazon Linux, Oracle Linux und Fedora CoreOS als eigene Infrastruktur-Hinweise aufgenommen.
2026-05-18: AWS-Stand auf Security Bulletin 2026-030 aktualisiert: Amazon-Linux-Updates sind für betroffene Kerneltracks verfügbar, Service-AMIs haben eigene Rollouts. Rocky-Security-Repo-Abschnitt um die zweite Dirty-Frag-Kernelrunde und die RxRPC/kernel-modules-partner-Einschränkung ergänzt. Proxmox-Abschnitt auf PSA-2026-00019-2 nachgezogen und um PSA-2026-00020-1 ergänzt, damit Dirty-Frag-Fixstände nicht als Fragnesia-Nachweis missverstanden werden.