Dirty Frag (CVE-2026-43284): Der Linux-Kernel-Bug, der Lesezugriff in Root verwandelt

Eine schreibgeschützte Datei sollte schreibgeschützt bleiben. Dirty Frag (CVE-2026-43284, CVE-2026-43500 und CVE-2026-46300) veranlasst den Linux-Kernel dennoch dazu, seine im Cache gespeicherte Kopie zu bearbeiten.

Dieser Fehler ermöglicht es einem Programm, das mit nahezu keinen Privilegien ausgeführt wird, in Dateien zu schreiben, die es eigentlich nur lesen dürfte, indem die vom Kernel im Arbeitsspeicher gehaltene Kopie geändert wird. Von dort aus kann es etwas umschreiben, dem das System vertraut, und sich selbst Root-Zugriff verschaffen. In Container-Umgebungen kann derselbe Trick, der den Host-Kernel erreicht, auch den von jedem Workload geteilten Node-Kernel erreichen.

Das anfällige Muster befindet sich seit Jahren im Netzwerkcode des Kernels, weshalb es bis in die meisten unterstützten Kernel-Versionen und fast jede wichtige Distribution zurückreicht. Linux hat die Schwachstelle gepatcht, und jede Distribution hat den Fix zurückportiert, sodass der Fix auf jeder Distribution unter einer anderen Versionsnummer geführt wird.

Übersicht zu Dirty Frag

Red Hat fasst drei CVEs unter Dirty Frag zusammen. Sie befinden sich in verschiedenen Bereichen des Netzwerkcodes des Kernels, und einer davon ist eine spätere Variante, die beim ersten Patch-Durchlauf übersehen wurde. Hier ist der direkte Vergleich.

Das Subsystem verrät Ihnen, ob das Problem für Sie relevant ist. Wenn Sie keine IPsec-VPNs oder AFS verwenden, ist das ein schneller Indikator dafür, wie stark Sie das Ganze kümmern muss. Anhand des Moduls überprüfen Sie (lsmod | grep -E 'esp4|esp6|rxrpc), was geladen ist.

Linux hält kürzlich aufgerufene Dateidaten im Speicher, damit nicht jedes Mal von der Festplatte gelesen werden muss. Diese Kopie im Arbeitsspeicher wird als Page-Cachebezeichnet. Bestimmte Kernelfunktionen wie splice() Diese gecachten Daten werden an den Networking-Code übergeben, ohne sie zu kopieren, indem stattdessen ein Zeiger auf den Speicherort übergeben wird, an dem sich die Daten bereits befinden. Das spart Rechenaufwand, solange jeder nachfolgende Schritt weiß, dass der Speicher gemeinsam genutzt wird, und nicht hineinschreibt.

Der Bug trat in zwei verschiedenen Bereichen des Netzwerk-Codes des Kernels auf. Einer davon ist ESP, das verschlüsselten VPN-Datenverkehr verarbeitet. Der andere ist RxRPC, ein älteres Protokoll, das hauptsächlich vom AFS-Dateisystem genutzt wird. Weder der ESP- noch der RxRPC-Pfad überprüft vor dem Schreiben, ob der Speicher gemeinsam genutzt wird.

Dies ermöglichte es einem Angreifer, eine schreibgeschützte Datei zu verwenden, die ihm bei Manipulation Privilegien verschaffen konnte, wie etwa /usr/bin/su, und deren Inhalt so in den Netzwerkpfad einzuspeisen, dass die fehlerhafte Entschlüsselung schließlich in den Speicher dieser Datei schrieb. Der Schreibvorgang landet im Page Cache, also der Kopie der Datei, die das System allen Programmen bereitstellt, die sie lesen. Die Datei auf der Festplatte verändert sich nie, aber die Version im Speicher spiegelt nun das wider, was der Angreifer daraus gemacht hat. Das Ausführen von su liest die manipulierte Kopie und verschafft dem Angreifer Root-Zugriff, obwohl er eigentlich nur Leserechte für diese Datei hatte.

Fragnesia, geführt als CVE-2026-46300, ist die jüngere Variante. Der Fix für Dirty Frag veranlasste den Kernel, sich auf eine Markierung zu verlassen, die besagt: „Dieses Fragment wird gemeinsam genutzt; erstelle eine sichere Kopie, bevor du es anfasst.“ Ein alter Bug aus dem Jahr 2013 im Code, der Paketfragmente zusammenfügt, entfernt diese Markierung jedoch klammheimlich. Er blieb dreizehn Jahre lang harmlos, da nichts von ihm abhing. Unglücklicherweise hing der Dirty Frag-Fix jedoch davon ab, was einen ruhenden Bug in einen neuen Pfad zum Root-Zugriff verwandelte. 

Warum ist Dirty Frag für Container wichtig?

Container teilen sich alle einen einzigen Kernel mit dem Host, sodass ein kompromittierter Container auf den anfälligen Kernel-Code zugreifen kann, wenn seine Berechtigungen dies zulassen (Syscall-/Namespace-/Security-Policy-Einstellungen). Forscher haben bereits funktionierende Proof-of-Concept-Exploits für Kubernetes veröffentlicht, und Ubuntu weist ausdrücklich auf das Risiko eines Container Escape hin. Wenn der Container den Kernel erreichen kann, droht ein Root-Zugriff auf den gesamten Node.

Sie können Teile des Angriffs stoppen, indem Sie Workloads als Non-Root ausführen, das RuntimeDefault-seccomp-Profil aktivieren, eingeschränkte Pod-Richtlinien durchsetzen und unprivilegierte Benutzer-Namespaces einschränken. Doch das behebt den eigentlichen Fehler nicht. Das kann nur ein Kernel-Update des Herstellers.

Wororan erkennen Sie, ob ein Host gefährdet ist?

Beginnen Sie mit dem Host, der tatsächlich läuft, nicht mit dem Dockerfile. Drei Befehle helfen dabei.

Führen Sie uname -r , um herauszufinden, welche Kernel-Version Sie verwenden, und vergleichen Sie diese dann mit der behobenen Version in den Sicherheitshinweisen Ihrer Distribution. Vergleichen Sie sie nicht mit der Upstream-Nummer. Das anfällige Muster reicht bis zu Kerneln aus dem Jahr 2017 zurück, und Enterprise- sowie LTS-Distributionen wie RHEL, Ubuntu und Debian backporten den Fix auf die ältere Kernel-Version, die Sie bereits ausführen. Daher kann ein gepatchter Kernel weiterhin eine Version von vor mehreren Jahren melden. Ein vollständig gepatchter RHEL 8-Host meldet nach wie vor 4.18, und dieser 4.18-Kernel enthält den Fix. Überprüfen Sie dies anhand der gepackten Version Ihres Anbieters.

lsmod | grep -E 'esp4|esp6|rxrpc zeigt an, ob der anfällige Codepfad geladen ist. Ein leeres Ergebnis bedeutet nicht automatisch Entwarnung, da diese Module bei Bedarf geladen werden. Und ein geladenes Modul ist nicht zwangsläufig ein Problem. esp4, esp6 und rxrpc sind ganz normale Module, die auf einem gepatchten Kernel völlig sicher sind. Dies zeigt Ihnen Ihre Angriffsfläche und ob sich die Anwendung der Blacklist-Minderungsmaßnahme lohnt.

sysctl user.max_user_namespaces zeigt, wie zugänglich der ESP-Pfad ist. Ein Wert größer als Null bedeutet, dass unprivilegierte Benutzer Namespaces erstellen können, was den üblichen Weg in den ESP-Pfad darstellt. Der Wert Null schließt diese Tür, allerdings nur für ESP. Der RxRPC-Pfad benötigt keine Namespaces und bietet daher keinen vollständigen Schutz.

Überprüfen Sie den Status bei Ihrem Anbieter. Red Hat gibt an, dass CVE-2026-43500 seine Produkte nicht betrifft, während CVE-2026-43284 und CVE-2026-46300 unterstützte Red Hat Enterprise Linux-Kernel und darauf basierende Systeme beeinträchtigen. Ubuntu veröffentlicht für jede unterstützte Kernellinie genau die Version, in der der Fehler behoben wurde.

Was sollten Sie überwachen?

Proof-of-Concept-Code ist bereits öffentlich verfügbar. Microsoft hat über vereinzelte Vorfälle in der Praxis berichtet , bei denen ein Angreifer mithilfe von suPrivilegien eskaliert, wobei jedoch angemerkt wird, dass es sich hierbei auch um Dirty Frag oder dessen Vorgänger Copy Fail handeln könnte, da sich die beiden anhand von Prozessprotokollen allein nur schwer unterscheiden lassen.

Der realistische Ort, um dies zu erkennen, sind die Audit- und EDR-Tools, die Sie bereits im Einsatz haben. Das Audit-Framework von Linux kann Prozessausführungen und setuid-Übergänge protokollieren. Genau dort würde die verdächtige Sequenz auftauchen: eine unbekannte Binärdatei wird abgelegt und ausgeführt, gefolgt unmittelbar von su. Achten Sie auf das Laden von esp4, esp6 oder rxrpc zeitgleich mit anderen verdächtigen Aktivitäten – insbesondere auf einem Host, der keinen ersichtlichen Grund hat, IPsec oder AFS zu nutzen –, sowie auf die Ausführung frisch abgelegter ELF-Dateien. 

Wenn Sie eine Ausnutzung vermuten, führen Sie Ihre Integritätsprüfungen von einer vertrauenswürdigen Umgebung aus und nicht von dem möglicherweise kompromittierten Host selbst. Und denken Sie daran, dass das Blockieren der Kernel-Module keine Seiten-Cache-Änderungen rückgängig macht, die ein Angreifer bereits vorgenommen hat.

Wo Aikido ansetzt

Die meisten Scans enden beim Image oder im Repository. Dirty Frag setzt eine Ebene tiefer an: im Kernel, den der Node tatsächlich bootet.

Aikido Security VM-Scan liest über einen Cloud-Snapshot aus, was auf dem laufenden Host tatsächlich installiert ist, sodass ein anfälliges Kernel-Paket als Host-Fund angezeigt wird. Da Hosts zudem mit den darauf laufenden Workloads und Konten verknüpft werden, sehen Sie sofort den Schadensradius, falls ein Node kompromittiert wird.

Für die mit Aikido verbundenen Cloud-Hosts zeigt der VM-Scan diejenigen an, die das anfällige Kernel-Paket enthalten, und weist aus, welche Workloads darauf laufen. Die Behebung bleibt gleich: Den Node-Kernel patchen und den geladenen Build nach dem Neustart bestätigen.

{{cta}}

FAQ