Eine Woche nach „Copy Fail“ (CVE-2026-31431) veröffentlichte der Forscher Hyunwoo Kim eine zweite Schwachstelle zur lokalen Rechteausweitung im Linux-Kernel, die denselben Bereich betrifft – IPsec ESP und rxrpc – und nannte sie „Dirty Frag“. Es gibt einen funktionierenden öffentlichen Proof-of-Concept. Jeder lokale Benutzer ohne Sonderrechte kann damit mit einem einzigen Befehl Root-Rechte erlangen.
Die Entwickler von KernelCare haben innerhalb von 24 Stunden nach Bekanntwerden der Sicherheitslücke Live-Patches für die gesamte EL8-Kernel-Familie bereitgestellt – noch vor den entsprechenden Errata der Hersteller –, wobei EL9, Ubuntu, Debian und Proxmox VE im Rahmen derselben Release-Welle folgten. Der Patch lässt sich auf den laufenden Kernel anwenden und wird ohne Neustart wirksam.
Ein zweiter öffentlich bekannter Exploit mit dem Namen„Copy Fail 2: Electric Boogaloo“bezieht sich unter diesem Alias auf dieselbe Sicherheitslücke. Es gibt keine separate CVE-Kennung für „Copy Fail 2“. Alle Angaben in diesem Hinweis gelten auch hier.
Hintergrund: Öffentlicher Proof-of-Concept und Bericht · Offenlegung bei oss-security · NVD-Eintrag für CVE-2026-43284 · Behebung durch den Upstream-Entwickler
Warum dies dringend ist
Die Schwachstelle liegt im In-Place-Entschlüsselungspfad von esp4, esp6 und rxrpc. Wenn der Empfangspfad über Paginierungs-Buffer entschlüsselt, die nicht im privaten Besitz des Kernels sind (z. B. Pipe-Seiten, die den Socket über splice(2) / sendfile(2) erreichen), können nicht privilegierte Prozesse Verweise auf den resultierenden Klartext behalten, was zu einer Schreiboperation in den Seiten-Cache führt, die der öffentliche PoC mit einem einzigen Befehl in Root-Rechte umwandelt.
Die Sperrfrist für die verantwortungsvolle Offenlegung wurde am 07.05.2026 gebrochen, bevor sich die Distributoren abstimmen konnten. Ein funktionierender Exploit wurde veröffentlicht, bevor CVE-IDs vergeben wurden und bevor die Errata der Hersteller fertiggestellt waren. Auf jedem System, auf dem nicht vertrauenswürdige Benutzer Code ausführen können, sollte dies als ein Fall behandelt werden, der eine Patching-Maßnahme am selben Tag erfordert.
Aktuelles zu den CVE-Zuweisungen:
- Die Sicherheitslücke im xfrm-ESP-Seiten-Cache beim Schreiben wird unter der Kennung CVE-2026-43284 geführt.
- Die Sicherheitslücke beim Schreiben in den Seiten-Cache von rxrpc ist unter der Kennung CVE-2026-43500 registriert (Eintrag im NVD steht noch aus).
KernelCare Live-Patches: ab sofort verfügbar, kein Neustart erforderlich
KernelCare stellte für alle unterstützten Distributionen Live-Patches bereit, noch bevor die Hersteller ihre Errata veröffentlichten:
- EL8-Familie (RHEL 8, CentOS 8, Oracle Linux 8, CloudLinux 8, CloudLinux 7 Hybrid, AlmaLinux 8, Rocky Linux 8)
- EL9-Familie (RHEL 9, AlmaLinux 9, Oracle Linux 9, Rocky Linux 9)
- Ubuntu 22.04 LTS (Jammy), einschließlich der Varianten AWS und HWE
- Debian 12 (Bookworm)
- Proxmox VE 7 (Kernel 5.15) und Proxmox VE 8
Kunden erhalten den Fix automatisch bei ihrem nächsten kcarectl –update.
Auch ELS für FIPS-Kernel werden behandelt
Die FIPS-validierten Kernel von TuxCare für den „Endless Lifecycle Support“ (ELS) für AlmaLinux 9.2 und 9.6 wurden gepatcht. ELS-FIPS-Kunden erhalten den Fix über denselben KernelCare-Bereitstellungskanal (Versionen K20260508_20 bzw. K20260508_19), ohne dass separate Maßnahmen erforderlich sind.
Was KernelCare-Kunden tun müssen
In den meisten Fällen geschieht nichts. Wenn die automatische Aktualisierung von kcarectl aktiviert ist (Standardeinstellung), wird der Patch bei der nächsten geplanten Abfrage abgerufen und angewendet. So wenden Sie ihn sofort an:
kcarectl --update
So überprüfen Sie, ob Sie auf dem neuesten Stand sind
Überprüfen Sie die Erstellungszeit des geladenen Patches:
kcarectl --info | grep kpatch-build-time
Jeder Patch, der am 8. Mai 2026 oder später datiert ist, enthält die Korrektur. Zur Überprüfung anhand der CVE-Referenz:
kcarectl --patch-info | grep -i 'CVE-2026-43284\|CVE-2026-43500\|dirty.frag\|xfrm'
Die von „uname -r“ zurückgegebene Kernel-Versionszeichenfolge ändert sich bei KernelCare nicht, da der laufende Kernel im Speicher gepatcht und nicht auf der Festplatte ersetzt wird.
Vorübergehende Abhilfe (falls Sie das Update nicht sofort durchführen können)
Falls die Anwendung des KernelCare-Live-Patches derzeit nicht möglich ist, setzen Sie die Module „esp4“, „esp6“ und „rxrpc“ auf die Blacklist, damit sie nicht geladen werden können, und entladen Sie sie, falls sie bereits vorhanden sind:
sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"
So machen Sie die Änderungen rückgängig, nachdem der Live-Patch angewendet wurde:
sudo rm /etc/modprobe.d/dirtyfrag.conf
Kompatibilität: esp4 und esp6 sind die kernelseitigen ESP-Transformationen, die von IPsec verwendet werden. Werden sie deaktiviert, führt dies zu einer Unterbrechung der IPsec-Tunnel, die auf dem betroffenen Rechner auf den Kernel-Datenpfad angewiesen sind. Wenden Sie diese Abhilfemaßnahme nicht auf Hosts an, die IPsec-, strongSwan- oder Libreswan-Tunnel beenden oder durchleiten. rxrpc ist der AF_RXRPC-Transport, der fast ausschließlich von AFS-Clients verwendet wird und auf typischen Webhosting-Servern nicht vorhanden ist.
Binärdateien im Seiten-Cache nach der Abhilfe wiederherstellen
Der Exploit kann im Rahmen der Root-Rechteerlangung legitime Systembinärdateien im Seiten-Cache verändern; daher reicht die Abhilfemaßnahme allein auf Systemen, die möglicherweise bereits vor ihrer Implementierung angegriffen wurden, nicht aus. Leeren Sie nach der Abhilfemaßnahme den Seiten-Cache:
echo 3 | sudo tee /proc/sys/vm/drop_caches
Links
- Canonical PoC (Hyunwoo Kim / V4bel)
- Forschungsbericht (dirtyfrag.io)
- Thread zur Offenlegung von Sicherheitslücken bei OSS
- Thread auf lore.kernel.org
- NVD-Eintrag für CVE-2026-43284
- Vorab-Korrektur (netdev/net.git-Commit f4c50a4034e62ab75f1d5cdd191dd5f9c77fdff4)
Sie nutzen KernelCare noch nicht?
KernelCare stellt Live-Patches für Kernel-CVEs für laufende Systeme bereit, ohne dass ein Neustart oder ein Wartungsfenster erforderlich ist. Das gleiche Bereitstellungsmodell, mit dem „Dirty Frag“ innerhalb von 24 Stunden nach der öffentlichen Bekanntgabe behoben wurde, gilt künftig für alle Kernel-CVEs mit hohem Schweregrad.
