DirtyClone und der „Shared-Frag“-Marker-Fehler, der immer wieder auftaucht

Die Kurzfassung

Zur Langfassung springen ↓

Was: DirtyClone, erfasst als 43503, ist eine lokale Privilegienausweitung im Linux-Kernel im Netzwerkstack: Bei einigen skb-Fragmentübertragungspfaden wird das SKBFL_SHARED_FRAG Marker, der In-Place-Schreibvorgänge blockiert, sodass ESP-Eingaben (IPsec) direkt über dateibasierte Seiten im Seiten-Cache entschlüsselt werden können. Das ist ein beliebiger Schreibvorgang in schreibgeschützte Dateien, deren Eigentümer „root“ ist – ein „Dirty COW“-Angriff über den Netzwerkstack anstelle von /proc/self/mem.

Auswirkungen: Ein lokaler Benutzer ohne Sonderrechte wandelt den Marker-Verlust in einen Schreibvorgang in den Seiten-Cache für eine Binärdatei um, wie zum Beispiel /usr/bin/su, und nutzt dann das manipulierte Image, um Root-Rechte zu erlangen. JFrog hat am 25. Juni eine Schritt-für-Schritt-Anleitung für den Exploit veröffentlicht; der öffentlich zugängliche PoC (rafaeldtinoco/security/exploits/dirtyclone, der auf Hyunwoo Kims „DirtyFrag“-Primitiv aufbaut) lässt sich auf älteren Kerneln reproduzieren. Die Datei auf der Festplatte ändert sich nie, sodass Tools zur Überprüfung der Dateiintegrität dies nicht erkennen.

Status: DirtyClone gehört zur DirtyFrag/Fragnesia-Familie: Ein Sicherheitsmarker geht verloren, wenn dateibasierter Speicher über schnelle Netzwerkpfade übertragen wird, und ein späterer In-Place-Schreibvorgang landet an der Stelle, an die er eigentlich hätte kopiert werden sollen. JFrog meldete den Fehler am 19. Mai; der Fix wurde am 24. Mai in v7.1-rc5 veröffentlicht. Damit handelt es sich um einen N-Day für RHEL-Umgebungen, in denen ein Teil der Fix-Kette fehlt, und nicht um einen neuen 0-Day.

Schweregrad: Red Hat stuft den Fehler als „Wichtig“ ein (CVSS 7.0); kernel.org bewertet ihn mit 8,8, was auf eine niedrigere Einstufung der Angriffskomplexität und eine Änderung des Geltungsbereichs (von „unverändert“ zu „geändert“) zurückzuführen ist, doch in beiden Fällen ist das Ergebnis Root-Rechte. Fehlerklasse: Ein Fehler bei der Weitergabe von Markern für gemeinsam genutzte Fragmente, der zu unsicheren In-Place-Schreibvorgängen in den durch den Seiten-Cache unterstützten Speicher führt.

Warum das wichtig ist: Bei den exponierten Systemen handelt es sich um solche, bei denen die Isolation das Ziel ist: Multi-Tenant-Hosts, CI-Runner, Container- und Kubernetes-Knoten sowie Entwicklungs-Sandboxes, die über CAP_NET_ADMIN, das viele Distributionen standardmäßig nicht privilegierten Benutzern innerhalb eines Namensraums gewähren. „Lokal“ bedeutet hier nicht „geringes Risiko“.

Mach das jetzt: Die Korrektur ist bereits in den EL9- und EL10-Feeds enthalten, führen Sie also ein Update durch und starten Sie das System neu. Falls Sie das Patch noch nicht installieren können, deaktivieren Sie die Namespaces für Benutzer ohne Sonderrechte oder blockieren Sie esp4/esp6 Autoload, wenn IPsec nicht verwendet wird. KernelCare Für betroffene EL9-/EL10-Kernel steht den Benutzern bereits ein Patch zur Verfügung, der keinen Neustart erfordert. Details dazu weiter unten.

Einige der schwerwiegendsten Fehler im Linux-Kernel beginnen nicht als offensichtliche Sicherheitslücke, bei der „in Root-Dateien geschrieben“ wird. Sie entstehen zunächst als Verwaltungsfehler. DirtyClone ist ein Beispiel dafür. Ein fehlender Eigentumsmarker bei Socket-Buffer-Fragmenten wird von einem späteren Netzwerkvorgang als vertrauenswürdig eingestuft, der dann direkt darüber hinwegschreibt.

Der Linux-Netzwerkstack transportiert Paketdaten in Socket-Puffern, sogenannten SKBs. Ein Teil dieser Daten liegt als Seitenfragmente vor, anstatt Byte für Byte in den privaten Speicher kopiert zu werden. Das ist gut für die Leistung, stellt jedoch hohe Anforderungen an die Eigentumsverhältnisse, da ein Fragment auf eine Seite verweisen kann, die gemeinsam genutzt wird, sich in fremdem Besitz befindet oder durch den Seiten-Cache abgesichert ist. Bevor Code in eine solche Seite schreibt, muss er wissen, dass es nicht sicher ist, diese Seite direkt zu bearbeiten.

Das ist die gesamte Aufgabe von SKBFL_SHARED_FRAG. Der Marker teilt dem nachfolgenden Code zur Paketverarbeitung mit, dass ein SKB gemeinsam genutzte Fragmente enthält und dass eine Änderung an Ort und Stelle nicht zulässig ist, es sei denn, der Kernel kopiert die Daten zuvor in den privaten Speicher. Ein „DirtyClone“ tritt auf, wenn dieser Marker beim Verschieben von Fragmenten von einem SKB in ein anderes verloren geht. NVD-Bezeichnungen __pskb_copy_fclone() und skb_shift() Zu den Helfern, die Frag-Deskriptoren verschieben können, ohne den Marker mitzunehmen, wodurch das Ziel-SKB über durch den Seiten-Cache gestützte Referenzen verfügt, während skb_has_shared_frag() gibt „false“ zurück.

Diese falsche Antwort ist die Sicherheitslücke. Ein späterer In-Place-Writer überprüft die SKB, fragt ab, ob die Fragmente gemeinsam genutzt werden, erhält die Antwort „nein“ und schreibt direkt in die zugrunde liegende Seite. ESP-Eingabe in esp4.c ist genau diese Art von Autor, und genau das ist der Abgrund, in den die Ausbeutung durch die Öffentlichkeit führt.

DirtyClone rundet eine Reihe dieser Fehler ab, die im Laufe des Frühjahrs aufgetreten sind und jeweils denselben Fehlermodus aufweisen. Der dateibasierte Seiten-Cache-Speicher wird wie gewöhnliche Paketdaten behandelt, woraufhin ein In-Place-Netzwerkvorgang an die Stelle schreibt, an die er eigentlich hätte kopieren sollen. „Copy Fail“ tauchte als erstes Ende April auf. „DirtyFrag“ folgte am 7. Mai. „Fragnesia“ umging am 13. Mai den „DirtyFrag“-Patch. „DirtyClone“ ist der vierte Fall, der über einen weiteren Pfad zum Klonen von Paketen erreicht wird, bei dem derselbe Ein-Bit-Marker entfernt wird.

Hier ist der Punkt, der Ihre Einstufung bestimmen sollte: Bei „DirtyClone“ handelt es sich nicht um einen brandneuen 0-Day-Exploit, der sich durch vollständig gepatchte Flotten frisst. Was JFrog am 25. Juni veröffentlicht hat, ist ein Nachweis dafür, dass durch einen unvollständigen Patch offen gelassene Restcodepfade weiterhin erreichbar sind. Das Schlüsselwort lautet „vollständig“. Ein Kernel ist erst dann geschützt, wenn er die gesamte DirtyFrag- und Fragnesia-Kette enthält. Ein Kernel, der den ursprünglichen DirtyFrag-Fix erhalten hat, bei dem jedoch die Folgepatches fehlten, weist weiterhin einen erreichbaren Pfad zu demselben ESP-Sink auf. Die aktuellen EL9- und EL10-Kernel von Red Hat enthalten bereits den vollständigen Backport, weshalb die Gefahr eher bei den Kerneln liegt, die einige Updates hinterherhinken, als bei den aktuellen Versionen.

So funktioniert DirtyClone

Die öffentliche Kette reicht von einer Socket-Konfiguration ohne Sonderrechte bis hin zu einem beliebigen Schreibvorgang in den Seiten-Cache mit Sonderrechten.

[Unprivileged user + network namespace]
│  attacker obtains CAP_NET_ADMIN inside the namespace
▼
[netfilter TEE rule clones ESP-in-UDP packets]
│  clone routed through __pskb_copy_fclone(), marker dropped
▼
[Mislabelled skb: references page-cache pages,
reports skb_has_shared_frag() == false]
▼
[XFRM ESP transport SA decrypts in place]
│  esp_input() AES-CBC writes over the target file's page cache
▼
[Arbitrary content in root-owned page cache]
│  overwrite /usr/bin/su (or /etc/sudoers.d/* via an NSS load)
▼
[uid=0 root shell]

Der Marker. Der Kernel kennzeichnet jedes SKB, das Seitenreferenzen enthält, die ihm nicht gehören, mit SKBFL_SHARED_FRAGund skb_has_shared_frag() liest dieses Tag aus, um zu entscheiden, ob eine Nutzlast an Ort und Stelle verändert werden kann. Wenn ein Frag-Transfer-Helper paginierte Fragmente zwischen SKBs verschiebt, ohne den Marker zu übertragen, behält das Ziel-SKB Verweise auf extern verwaltete oder durch den Seiten-Cache gestützte Seiten bei, meldet jedoch, dass nichts gemeinsam genutzt wird.

Das Waschbecken. Ein späterer In-Place-Writer verlässt sich auf diesen Bericht. Im Fall von DirtyClone ist der Writer esp_input() AES-CBC-Entschlüsselung, bei der diese Seiten direkt entschlüsselt werden, einschließlich des Seiten-Caches von Dateien, die dem Root-Benutzer gehören und schreibgeschützt sind. Mit der Kontrolle über den ESP-Schlüssel und die Sicherheitsassoziation sowie die eingefügten Quellseiten nutzt der Angreifer dies aus, um beliebige Inhalte in den privilegierten Seiten-Cache zu schreiben.

Die Route. Red Hat führt die Bekanntheit von EL9 und EL10 auf skb_try_coalesce() der Verlust des Markers (Bugzilla 2480902) und weist darauf hin, dass derselbe Verlust auch bei einer ganzen Familie von Helfern auftreten kann, darunter __pskb_copy_fclone(), skb_shift(), skb_gro_receive()und skb_segment(). Der öffentliche PoC gelangt über einen anderen Weg zum identischen ESP-Sink. Er läuft innerhalb eines nicht privilegierten Benutzer- und Netzwerk-Namespace, installiert eine netfilter-TEE-Regel, die ESP-in-UDP-Pakete über __pskb_copy_fclone(), wodurch der Marker entfernt wird; anschließend werden XFRM-ESP-Transport-SAs eingerichtet, sodass das geklonte, falsch beschriftete Paket direkt im Seitencache der Zieldatei entschlüsselt wird.

Das Wichtigste ist, dass es sich hierbei nicht um eine Bearbeitung handelt /usr/bin/su auf der Festplatte im herkömmlichen Sinne. Es verfälscht die im Arbeitsspeicher befindliche Kopie im Seiten-Cache, die der Kernel später an einen privilegierten Ausführungspfad weitergibt. Genau das macht die herkömmliche Überwachung der Dateiintegrität in diesem Fall zu einer schwachen Kontrollmaßnahme. Die Datei auf der Festplatte bleibt unberührt, die Änderung befindet sich in der im Arbeitsspeicher befindlichen Kopie des Kernels, und ein Neustart stellt die ursprüngliche Binärdatei wieder her – meist erst, lange nachdem der Angreifer bereits Root-Rechte erlangt hat.

Ein Detail ist für den Geltungsbereich von Bedeutung. In der README-Datei des PoC wird ein enges Zeitfenster für die Mainline-Versionen v7.1-rc1 bis rc4 genannt, doch bei internen Tests lässt sich das Problem unverändert auf den zurückportierten EL9- und EL10-Kerneln reproduzieren. Dieses Upstream-Zeitfenster schränkt die Auswirkungen auf Distributionen der RHEL-Familie nicht ein. Ziehen Sie aus dem in der README-Datei angegebenen Versionsbereich nicht den Schluss, dass Ihr EL-System nicht betroffen ist.

Was sich durch den Upstream-Fix ändert

Der Fix ist klein, und genau deshalb bringt die Familie immer wieder neue Varianten hervor. Er bewirkt, dass die Frag-Transfer-Helfer den Shared-Frag-Marker weitergeben, sodass ein Ziel-SKB, das noch auf Seiten verweist, die durch den Seiten-Cache abgesichert sind oder externem Besitz unterliegen, Folgendes meldet: skb_has_shared_frag() als wahr. Der spätere In-Place-Writer weigert sich daraufhin, diese Seiten zu ändern, und greift stattdessen auf eine sichere Kopie zurück. Der Fix wurde am 21. Mai im Upstream übernommen und am 24. Mai in Linux v7.1-rc5 veröffentlicht – als Teil derselben Serie, mit der auch die früheren „DirtyFrag“-Fehler behoben wurden. Die Commit-IDs für die stabile Version und die Backports variieren je nach Zweig; orientieren Sie sich daher lieber an den Hinweisen Ihrer Distribution als an einem einzelnen Upstream-Hash.

Wer ist betroffen?

Für allgemeine Linux-Benutzer besteht ein Risiko, wenn dem laufenden Kernel die vollständige Kette von Patches für „DirtyFrag“, „Fragnesia“ und „DirtyClone“ fehlt und das System es nicht vertrauenswürdigem lokalem Code ermöglicht, auf die Netzwerkfunktionen zuzugreifen, die der Exploit benötigt. Öffentlichen Berichten zufolge gehören Debian, Fedora und Ubuntu zu den Distributionen, bei denen nicht privilegierte Benutzernamensräume unter gängigen Konfigurationen die Ausnutzung der Schwachstelle erleichtern. Ubuntu 24.04 und spätere Versionen enthalten AppArmor-Einschränkungen, die den standardmäßigen Exploit-Pfad blockieren können; dies stellt jedoch lediglich eine Absicherung für einen bestimmten Pfad dar und ist kein Beweis dafür, dass der zugrunde liegende Kernel behoben ist.

Bei Systemen der RHEL-Familie ist das Bild überschaubarer, und es läuft letztlich auf zwei Fragen hinaus: Ist der Kernel von den „DirtyFrag“- und „Fragnesia“-Errata betroffen, und wird auf dem Host ein Patch ohne Neustart ausgeführt?

Ausnutzbar, intern auf Kerneln reproduziert, bei denen die vollständige Kette fehlt:

• EL9 ein 5.14.0-611.49.2.el9_7, überschreibt /usr/bin/su und Erträge uid=0.
• EL10 ein 6.12.0-55.27.1.el10_0, dasselbe Ergebnis.

Nicht anfällig:

• Aktuelle Stock-Kernel, die bereits die vollständige Korrektur für „DirtyFrag“ und „Fragnesia“ enthalten, zum Beispiel EL10 6.12.0-211.16.1.el10_2, wo sich der PoC nicht reproduzieren lässt.
• Jeder Host, der durch den „rebootless“-Patch auf dem esp4 Modul.

Nicht von CVE-2026-43503 betroffen:

• RHEL 6, 7 und 8. Red Hat stuft diese Versionen hinsichtlich dieser spezifischen CVE als nicht betroffen ein. Dies ist eng auszulegen. Die Listen der betroffenen Streams unterscheiden sich innerhalb der DirtyFrag-Familie, sodass ein Stream, der für CVE-2026-43503 als nicht betroffen gilt, nicht zwangsläufig auch für alle damit zusammenhängenden CVEs als nicht betroffen gilt.

Red Hat führt RHEL 9 und RHEL 10 sowie OpenShift RHCOS als betroffene Code-Streams für CVE-2026-43503 auf. Damit wird der betroffene Code-Stream gekennzeichnet, nicht ein vollständig aktualisierter Host. „Betroffen“ ist in diesem Zusammenhang so zu verstehen, dass „dieser Code hier ausgeliefert wurde“, und nicht, dass „jeder aktuelle RHEL 9- oder 10-Rechner heute angreifbar ist“.

Der Zeitpunkt der Veröffentlichung variiert zudem je nach Distribution und Kernel-Version. Insbesondere CloudLinux (CL8 und CL9) kann bei dieser Produktfamilie hinter den EL-Feeds zurückbleiben, daher sollten CL-Nutzer ihre genaue Version überprüfen, anstatt von einer Übereinstimmung auszugehen.

Ein Hinweis, der für die gesamte Familie gilt: Ein Host, der die Annahmen des PoC einfach nicht erfüllt, ist nicht dasselbe wie ein Host, bei dem das Problem behoben wurde. Vergewissern Sie sich, dass der Kernel die vollständigen Errata enthält, anstatt davon auszugehen, dass Sie sicher sind, nur weil ein Exploit-Versuch fehlgeschlagen ist.

Jetzt Maßnahmen ergreifen

Die dauerhafte Lösung ist ein gepatchter Kernel oder ein Patch, der ohne Neustart installiert werden kann. Bis dies flächendeckend verfügbar ist, sind die Maßnahmen sinnvoll, die die Voraussetzungen für die Ausnutzung der Sicherheitslücke beseitigen.

1. Führen Sie zunächst einen Patch durch oder wenden Sie einen Patch an, der keinen Neustart erfordert

Installieren Sie den korrigierten Kernel Ihrer Distribution und starten Sie das System damit neu, oder wenden Sie einen Patch an, der keinen Neustart erfordert, falls ein Neustart nicht möglich ist. Die Korrektur ist bereits in den EL9- und EL10-Repositories enthalten, sodass es sich auf den meisten Hosts eher um ein Update als um eine Wartezeit handelt.

2. Namensräume für Benutzer ohne Sonderrechte einschränken

Die Kette benötigt CAP_NET_ADMIN Ein nicht privilegierter Benutzer muss die TEE-Regel und die XFRM-SA installieren. Nimmt man das weg, funktioniert der öffentliche Pfad nicht mehr.

# EL family:
sudo sysctl -w user.max_user_namespaces=0
echo 'user.max_user_namespaces = 0' | sudo tee /etc/sysctl.d/99-dirtyclone.conf

# Debian / Ubuntu:
sudo sysctl -w kernel.unprivileged_userns_clone=0
echo 'kernel.unprivileged_userns_clone = 0' | sudo tee /etc/sysctl.d/99-dirtyclone.conf

Auswirkungsbereich. Dies führt dazu, dass rootless Podman und rootless Docker nicht mehr funktionieren, unshare(1), die Sandbox von Chromium, einige CI-Sandboxen und bwrap-Flatpaks. Auf den meisten streng gesicherten Serverflotten akzeptabel, auf Container- und Entwickler-Hosts jedoch störend. Vor einer flächendeckenden Einführung testen.

3. Das automatische Laden des ESP-Moduls unterbinden, wenn IPsec nicht verwendet wird

Nein esp4 oder esp6, keine In-Place-Entschlüsselungsstelle für den DirtyClone-Pfad.

echo -e 'install esp4 /bin/false\ninstall esp6 /bin/false' | sudo tee /etc/modprobe.d/dirtyclone-esp.conf

Wenden Sie dies nicht auf Hosts an, die IPsec oder XFRM verwenden, da dadurch der ESP-Transport deaktiviert wird und Ihre Tunnel unterbrochen werden. Ein Hinweis für die gesamte Familie: Die früheren Arbeiten zu „DirtyFrag“ hatten ebenfalls Auswirkungen auf rxrpc als In-Place-Write-Sink; daher kann eine Absicherung gegen die gesamte Familie bedeuten, dass rxrpc auch. Diese Änderung führt zu Fehlern bei AFS und anderen RxRPC-abhängigen Workloads; wenden Sie sie daher nur mit Bedacht an und ausschließlich dort, wo diese Funktionen nicht genutzt werden. Um die Änderung rückgängig zu machen, entfernen Sie die Drop-in-Dateien und laden Sie sie erneut.

sudo rm -f /etc/modprobe.d/dirtyclone-esp.conf /etc/sysctl.d/99-dirtyclone.conf
sudo sysctl --system

Entscheidungsmoment. Wenn der Host weder IPsec noch rootless Container ausführt, funktioniert jede der beiden Möglichkeiten, wobei der ESP-Modul-Block die geringfügigere Änderung darstellt. Wenn IPsec benötigt wird, aber keine rootless Container, deaktivieren Sie nicht privilegierte Benutzer. Wenn sowohl IPsec als auch rootless Container benötigt werden, ist ein Patch ohne Neustart oder ein korrigierter Kernel die einzige Lösung, die den Betrieb nicht unterbricht, und Sie sollten nicht vertrauenswürdige lokale Ausführungen isolieren, bis eine dieser Lösungen implementiert ist.

Rebootloses Patchen

Genau für solche Fehler gibt es Lösungen zum Patchen ohne Neustart, wie beispielsweise KernelCare. Ein Neustart einer gesamten Serverflotte mit einem korrigierten Kernel ist zwar leicht gesagt, aber schwer zu planen, und das unterbrechungsfreie Patchen schließt dieselbe Lücke, ohne die Verfügbarkeit zu beeinträchtigen.

Bei den betroffenen EL9- und EL10-Kerneln landet es auf dem esp4 Modul und deaktiviert den ESP-Eingabe-Entschlüsselungs-Sink genau an der Stelle, an der der unsichere Schreibvorgang stattfinden würde. Fehlt der Marker für gemeinsam genutzte Fragmente aufgrund des Ausbreitungsfehlers, wird die In-Place-Entschlüsselung von Fragmenten, die durch den Seiten-Cache abgesichert sind, abgelehnt, anstatt sie durchzuführen. Gleiche Garantie wie bei der Marker-Korrektur im Upstream, nur dass dies ohne Eingriff in ein Wartungsfenster erfolgt.

Da DirtyClone und CVE-2026-46300 denselben Grundfehler und denselben Fix haben, deckt ein einziger Patch ohne Neustart beide ab. Das sollten Sie bei der Überprüfung der Abdeckung beachten: In manchen Tools wird der Schutz unter der verwandten CVE-2026-46300 statt unter CVE-2026-43503 angezeigt, da die CVE-Kennzeichnung hinter dem eigentlichen Fix zurückbleiben kann.

Der Nutzen ist hier zwar begrenzt, aber real, und genau darin liegt die Stärke von Patches ohne Neustart. Am stärksten gefährdet sind jene Hosts, bei denen die Kernel-Updates im Rückstand sind – und genau bei diesen Hosts ist ein Notfall-Neustart von vornherein am schwierigsten zu planen. Die Möglichkeit, DirtyClone auf diesen Hosts ohne einen solchen Neustart zu schließen, macht den Unterschied zwischen einer Behebung noch heute und einer Behebung erst im nächsten Wartungsfenster aus – und für viele Serverflotten liegt genau in dieser Lücke das eigentliche Risiko.

Erkennung

Es gibt keine zuverlässige Signatur für „DirtyClone“ auf der Festplatte, und genau darin liegt ein wesentlicher Teil des Risikos. Die Manipulation findet im Seiten-Cache statt, die Binärdatei auf der Festplatte bleibt unberührt, und durch das Leeren des Caches oder einen Neustart werden die ursprünglichen Bytes wiederhergestellt. Dadurch werden jedoch weder die Persistenz noch Kontoänderungen oder nachfolgende Aktivitäten rückgängig gemacht, die der Angreifer nach dem Erlangen von Root-Rechten durchgeführt hat. Das Hashen von Dateien ist in diesem Fall eine schwache Sicherheitsmaßnahme.

Es hinterlässt zwar keine offensichtlichen Anzeichen für eine Beeinträchtigung der Dateiintegrität, ist aber dennoch nicht unsichtbar. Die Erkennung erfolgt eher anhand von Verhaltensdaten, und jeder der folgenden Punkte ist eher ein Hinweis als ein Beweis:

• Unerwartet esp4 oder esp6 Das Modul wird auf Hosts geladen, auf denen IPsec nicht ausgeführt wird.
• Erstellung eines nicht privilegierten Benutzernamensraums, kurz darauf gefolgt von der Installation von XFRM SA oder dem Einfügen einer netfilter-TEE-Regel.
• Ungewöhnlich nft, iptables, XFRM- oder TEE-Aktivitäten, die aus lokalen Benutzerkontexten stammen.
• Ausführung einer setuid-Binärdatei wie beispielsweise su oder sudo unmittelbar nach dieser Netzwerkkonfiguration, und zwar von einem Benutzer, der keinen Grund hatte, an beidem etwas zu ändern.
• Ein plötzliches Ausbleiben erwarteter Sicherheitsüberprüfungsereignisse auf einem Host, der diese eigentlich erzeugen sollte.

Sollte während des Zeitfensters nicht vertrauenswürdiger oder nur bedingt vertrauenswürdiger lokaler Code auf einem exponierten EL9- oder EL10-Host ausgeführt worden sein, sollten Sie der Installation von Patches Priorität einräumen und den Host als besonders prüfungsbedürftig einstufen, anstatt das Fehlen von Beweisen auf der Festplatte als Zeichen dafür zu werten, dass keine Kompromittierung vorliegt.

Warum gerade dieses Thema wichtig ist

Bei „DirtyClone“ handelt es sich nicht um eine Remote-Code-Ausführung, und es bedeutet auch nicht, dass ein nicht authentifizierter Internetnutzer auf jedem Linux-Server Root-Rechte erlangen kann. Für die Umgebungen, in denen dieser Fehler tatsächlich auftritt, ist diese Unterscheidung jedoch ein schwacher Trost. CI-Runner führen den Code anderer aus. Shared-Hosting-Plattformen führen Kundencode aus. Kubernetes-Knoten führen Container mit unterschiedlichen Vertrauensstufen aus. Entwickler-Sandboxes und Build-Hosts erlauben oft genau das Namespace-Verhalten, das diese Klasse erreichbar macht. In jedem dieser Fälle ist eine lokale Privilegieneskalation das auslösende Ereignis. Sie verwandelt Code, der dort lief, wo er erlaubt war, in Code, der Root-Rechte erlangte, wo dies niemals vorgesehen war.

Der Grund, warum „DirtyClone“ weniger dringlich ist, als die Schlagzeilen vermuten lassen, ist zugleich der Grund, warum man hier leicht ins Fettnäpfchen treten kann. Ein Kernel, der die vollständige „DirtyFrag“- und „Fragnesia“-Kette enthält, ist geschützt. Doch „vollständig“ ist hier das entscheidende Wort. Ein Kernel, der den ursprünglichen „DirtyFrag“-Patch übernommen hat und dann nicht weiter aktualisiert wurde, weist nach wie vor eine angreifbare Schwachstelle auf – ebenso wie jeder Host, der bei den Backports der Distribution hinterherhinkt. Das Risiko konzentriert sich auf die Rechner, die das letzte Wartungsfenster übersprungen haben, auf die langlebigen CI-Runner, die niemand neu startet, und auf die Server, die für das nächste Quartal beiseitegestellt wurden. Genau das sind die Hosts, auf denen ein N-Day-Problem wie dieses still und leise zu einem Problem noch am selben Tag wird. Ein reiner Scanner-Workflow, der sich auf den betroffenen Kernel-Stream konzentriert, ohne die gesamte Fix-Kette zu überprüfen, kann entweder bei gepatchten Hosts falschen Alarm auslösen oder diejenigen übersehen, die noch gefährdet sind.

Checkliste für priorisierte Sanierungsmaßnahmen

1. Wenden Sie zunächst einen Patch oder einen Patch ohne Neustart auf EL9- und EL10-Systeme an, bei denen die Kernel-Updates noch ausstehen – insbesondere auf Container-Hosts, CI-Runner, gemeinsam genutzte Systeme und Multi-Tenant-Umgebungen.
2. Stellen Sie sicher, dass der aktuell ausgeführte Kernel die vollständige Kette von Korrekturen für „DirtyFrag“, „Fragnesia“ und „DirtyClone“ enthält, anstatt die Sicherheit allein aus einem fehlgeschlagenen Exploit-Versuch abzuleiten.
3. Eine teilweise Behebung von „DirtyFrag“ ist weiterhin als Sicherheitslücke zu betrachten. Nur die vollständige Kette schließt den Pfad.
4. Bei der Überprüfung der Abdeckung durch den „rebootless-patch“ ist zu beachten, dass der Schutz in einigen Tools zunächst unter CVE-2026-46300 angezeigt wird, bis die Zuordnung zu CVE-2026-43503 übernommen wurde.
5. Bei CloudLinux CL8 und CL9 kann es bei den EL-Feeds für diese Produktfamilie zu Verzögerungen kommen. Überprüfen Sie daher bitte Ihre genaue Produktreihe.
6. Deaktivieren Sie nicht privilegierte Benutzernamensräume, sofern die Arbeitslast dies zulässt.
7. Block esp4 und esp6 Autoload, wenn IPsec nicht verwendet wird, und rxrpc Das gilt auch, wenn Sie sich gegen die erweiterte Familie absichern und weder AFS noch RxRPC verwenden.
8. Suche nach ungewöhnlichen Namespaces: XFRM, ESP, TEE, nft, suund sudo Aktivität während des Expositionsfensters und betrachten saubere Datei-Hashes als unzureichenden Beweis.

Patches für jeden Kernel – ganz ohne Neustart. Wenn Sie KernelCare noch nicht nutzen, ist jetzt der richtige Zeitpunkt, um zu erfahren, wie Patches ohne Neustart kritische Linux-Systeme schützen – ganz ohne Notfall-Wartungsfenster oder Ausfallzeiten.

Holen Sie sich KernelCare noch heute →

Referenzen

• Red Hat CVE-2026-43503, Wichtig, CVSS 7.0, RHEL 9 und 10 betroffen, RHEL 6/7/8 nicht betroffen; Bugzilla 2480902
• Red Hat-Sicherheitsdaten im JSON-Format, CVE-2026-43503
• NVD CVE-2026-43503 (kernel.org CNA-Wert 8,8, Umfang geändert)
• Debian Security Tracker, CVE-2026-43503
• Verwandter Eintrag CVE-2026-46300 (Bugzilla 2477015), derselbe Grundfehler über skb_try_coalesce, erklärt die Lösung
• JFrog Security Research: „Analyse und Ausnutzung einer Linux-LPE-Variante: DirtyClone (CVE-2026-43503)“
• SecurityWeek: Sicherheitslücke im „DirtyClone“-Linux-Kernel ermöglicht Root-Zugriff
• The Hacker News: Neue „DirtyClone“-Sicherheitslücke im Linux-Kernel ermöglicht lokalen Benutzern den Zugriff auf Root-Rechte über geklonte Pakete
• Öffentlicher PoC, rafaeldtinoco/security/exploits/dirtyclone (JFrog; Hyunwoo Kim, „DirtyFrag“-ESP-Primitiv)
• Korrektur im Hauptzweig von Linux v7.1-rc5