Am 13.05.2026 fand der Sicherheitsforscher William Bowling eine weitere Schwachstelle in Kernels von Linux Systemen. Auch hier handelt es sich um eine lokale Rechtausweitung, die eine Kombination aus drei Subsystemen ausnutzt. Das XFRM-Framework (IPsec), den TCP ULP-Mechanismus (Upper Layer Protocol) und den Splice-Syscall mit Page-Cache-Sharing, wobei ein willkürlicher Write in den VFS Page Cache, ohne root Rechte, erfolgt.<\/p>\n\n\n\n
Ein normaler Benutzer erstellt zunächst einen eigenen User- und Netzwerk-Namespace. Dadurch erhält der Prozess innerhalb dieser isolierten Umgebung Netzwerk-Adminrechte ( Mit diesen Rechten richtet der Angreifer eine manipulierte IPsec-Konfiguration (Security Association) ein und nutzt anschließend einen Fehler im Zusammenspiel von Dadurch kann der Angreifer den Inhalt eines System-Binaries wie Schritt 1: Eigene isolierte Umgebung erstellen<\/strong><\/p>\n\n\n\n Namespaces sind normalerweise zur Isolation von Ressourcen, Prozessen oder Daten gedacht, wobei sie darin dem Prozess aber genug Rechte geben, um bestimmte Netzwerkfunktionen des Kernels zu konfigurieren.<\/p>\n\n\n\n In dieser Schwachstelle nutzt der Angreifer das und erstellt zunächst einen neuen User – und Netzwerk – Namespace mit: Dadurch bekommt der Prozess innerhalb dieser isolierten Umgebung Netzwerk-Adminrechte ( Schritt 2: IPsec-Verbindung mit bekanntem Schlüssel anlegen<\/strong><\/p>\n\n\n\n Der Angreifer richtet über Dabei wird verwendet:<\/p>\n\n\n\n Da der Angreifer den Schlüssel selbst festlegt, weiß er genau, wie der Kernel später Daten ver- und entschlüsselt. Dadurch kann er gezielt beeinflussen, welche Bytes bei der Entschlüsselung im Speicher verändert werden.<\/p>\n\n\n\n Schritt 3 : Tabelle vorberechnen, um gezielt Bytes zu verändern<\/strong><\/p>\n\n\n\n Nachdem die Security Association eingerichtet wurde, berechnet der Angreifer vorbereitend viele mögliche Verschlüsselungszustände durch. Hintergrund ist, dass AES-GCM intern mit einem sogenannten Counter-Mode arbeitet. Dabei erzeugt der Algorithmus einen Keystream, der später per XOR auf die Daten angewendet wird.<\/p>\n\n\n\n Da der Angreifer den Schlüssel kennt und bestimmte Werte wie den IV (Initialisierungsvektor bzw. Nonce) selbst kontrollieren kann, lässt sich genau vorhersagen, welche Bytes der Kernel später erzeugen wird. Durch das systematische Variieren dieser Werte erstellt der Angreifer eine Art Nachschlagetabelle: Für nahezu jede gewünschte Byte-Veränderung gibt es einen passenden IV.<\/p>\n\n\n\n Damit besitzt er später die Möglichkeit, einzelne Bytes im Speicher gezielt zu verändern, ohne direkt auf die Datei schreiben zu müssen.<\/p>\n\n\n\n Schritt 4: Ausnutzen der eigentlichen Schwachstelle<\/strong><\/p>\n\n\n\n Wie in den vorherigen Kernel CVEs, verwendet der Angreifer die Funktion Anschließend aktiviert der Angreifer Hierbei geht der Kernel davon aus, dass der Speicher ausschließlich zum Socket gehört. Er erkennt nicht, dass dieselbe Speicherseite gleichzeitig Teil des Dateisystem-Caches einer eigentlich schreibgeschützten Datei ist.<\/p>\n\n\n\n Dadurch wird der kryptographische Output direkt auf den Page Cache angewendet. Der Entschlüsselungsvorgang verändert also ungewollt den Inhalt einer Systemdatei im Speicher.<\/p>\n\n\n\n Schritt 5: Gezieltes Überschreiben einzelner Bytes<\/strong><\/p>\n\n\n\n Der Angriff wird nun mehrfach wiederholt, um die gewünschte Datei Schritt für Schritt zu manipulieren.<\/p>\n\n\n\n Für jedes Byte berechnet der Angreifer zunächst den Unterschied zwischen dem aktuellen Wert und dem gewünschten Zielwert. Anschließend sucht er in seiner vorberechneten Keystream-Tabelle nach einem passenden IV, der genau diese Veränderung erzeugt.<\/p>\n\n\n\n Danach wird ein neuer ESP-Datensatz erzeugt und erneut durch die fehlerhafte Entschlüsselungsroutine verarbeitet. Auf diese Weise lassen sich einzelne Bytes kontrolliert verändern, obwohl die Datei eigentlich schreibgeschützt ist.<\/p>\n\n\n\n Der Vorgang wird so oft wiederholt, bis der gewünschte Payload vollständig im Speicher liegt.<\/p>\n\n\n\n Schritt 6: Ausführung des manipulierten Programms<\/strong><\/p>\n\n\n\n Am Ende befindet sich im Page Cache eine manipulierte Version von Wird das Programm anschließend gestartet, verwendet der Kernel zunächst den bereits vorhandenen Cache-Inhalt. Dadurch wird nicht mehr der originale Code ausgeführt, sondern die manipulierte Version.<\/p>\n\n\n\n Der eingeschleuste Code setzt die Benutzer- und Gruppen-ID auf Root und startet anschließend eine Shell. Dadurch erhält der Angreifer Root-Rechte, obwohl er ursprünglich keinerlei privilegierten Zugriff auf das System hatte.<\/p>\n\n\n\n Quelle:<\/p>\n\n\n\n Alle drei Schwachstellen unterliegen dem gleichen Grundmuster, bei dem der Kernel so manipuliert wird, dass er einen Schreibvorgang direkt auf einer Page Cache Seite durchführt, auf die ein unprivilegierter Nutzer eigentlich nur lesend zugreifen darf. Das Ergebnis ist jeweils, ein zuverlässiger Root-Exploit gegen CopyFail nutzt das Dirty Frag und Fragnesia benötigen beide Der Unterschied zwischen Dirty Frag und Fragnesia liegt vor allem im Aufbau des Exploits. Dirty Frag kombiniert zwei getrennte Kernel-Bugs. Einen im Fragnesia dagegen basiert nur auf einem einzelnen Bug. Beim Coalescing (dem Zusammenführen mehrerer Netzwerkfragmente) verliert ein Beim aktuellen Patch-Status ist Fragnesia das kritischste Problem. CopyFail wird zwar bereits aktiv ausgenutzt, ist aber schon gepatcht. Für Dirty Frag existiert ebenfalls bereits ein Upstream-Patch (ein bereits in die offizielle Kernel-Entwicklung integrierter Fix). Für Fragnesia gibt es aktuell nur einen Patch auf der Netdev-Mailingliste (der zentralen Mailingliste für Linux-Netzwerkentwicklung), dieser wurde bisher weder in den Mainline-Kernel noch in Stable-Kernel übernommen.<\/p>\n\n\n\n Als Schutzmaßnahme können die betroffenen Kernel-Module deaktiviert beziehungsweise geblacklistet werden:<\/p>\n\n\n\n Innerhalb von zwei Wochen, CopyFail am 29. April, Dirty Frag am 7. Mai, Fragnesia am 13. Mai, wurden drei Root-Exploits auf denselben Linux-Kernel-Pfad offengelegt. Alle drei Schwachstellen wurden mit Unterstützung großer Sprachmodelle entdeckt und kurz nach der Entdeckung veröffentlicht.<\/p>\n\n\n\n Die neue Schwachstelle DirtyCBC zeigt, dass die oben genannten Schwachstellen wahrscheinlich kein Einzelfall bleiben. Auch DirtyCBC folgt demselben Muster. Der Kernel verarbeitet Daten direkt auf Speicherseiten, die über Für Schwachstellen dieser Klasse ist das zugrunde liegende Muster inzwischen relativ klar erkennbar und damit auch systematisch analysierbar. Dabei werden Kernel-Pfade gesucht, in denen In-Place-Kryptografie direkt auf externen oder gemeinsam genutzten Puffern ausgeführt wird, ohne vorher eindeutig zu prüfen, wem diese Speicherbereiche tatsächlich gehören und ob sie überhaupt beschrieben werden dürfen. Gerade hier wird KI in zukunft die Entwicklung massiv beschleunigen, da nicht nur einzelne Codefragmente analysieren werden, sondern auch Commit-Historien, Patches, Subsystem-Zusammenhänge und wiederkehrende Bugmuster. Das führt dazu, dass deutlich mehr Schwachstellen mit demselben Grundmuster entdeckt werden. Besonders betroffen dürften weiterhin komplexe Kernel-Bereiche sein, in denen Netzwerk-Stacks, Kryptografie, Aus diesem Grund werden zukünftige Schwachstellen dieser Art voraussichtlich überwiegend zusammengefasst betrachtet und nur besonders kritische CVEs noch einzeln behandelt.<\/p>\n","protected":false},"excerpt":{"rendered":" Am 13.05.2026 fand der Sicherheitsforscher William Bowling eine weitere Schwachstelle in Kernels von Linux Systemen. Auch hier handelt es sich um eine lokale Rechtausweitung, die eine Kombination aus drei Subsystemen ausnutzt. Das XFRM-Framework (IPsec), den TCP ULP-Mechanismus (Upper Layer Protocol) und den Splice-Syscall mit Page-Cache-Sharing, wobei ein willkürlicher Write in den VFS Page Cache, ohne […]<\/p>\n","protected":false},"author":36,"featured_media":38219,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"content-type":"","_eb_attr":"","footnotes":""},"categories":[334],"tags":[],"class_list":["post-38208","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-schwachstellen"],"_links":{"self":[{"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/posts\/38208","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/users\/36"}],"replies":[{"embeddable":true,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/comments?post=38208"}],"version-history":[{"count":3,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/posts\/38208\/revisions"}],"predecessor-version":[{"id":38223,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/posts\/38208\/revisions\/38223"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/media\/38219"}],"wp:attachment":[{"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/media?parent=38208"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/categories?post=38208"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/tags?post=38208"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}CAP_NET_ADMIN<\/code>), obwohl er auf dem eigentlichen System kein Root ist.<\/p>\n\n\n\nsplice()<\/code>, espintcp<\/code> und dem Linux-Page-Cache aus. Der Kernel entschlüsselt Daten direkt im Speicher und merkt dabei nicht, dass dieser Speicher gleichzeitig zum Cache einer schreibgeschützten Systemdatei gehört.<\/p>\n\n\n\n\/usr\/bin\/su<\/code> im Arbeitsspeicher gezielt verändern und beim nächsten Start des Programms Root-Rechte erhalten.<\/p>\n\n\n\nAusführliche Erklärung:<\/strong><\/h3>\n\n\n\n
unshare(CLONE_NEWUSER | CLONE_NEWNET)<\/code><\/p>\n\n\n\nCAP_NET_ADMIN<\/code>).
Wichtig: Auf dem eigentlichen System hat der Angreifer weiterhin keine Root-Rechte.<\/p>\n\n\n\nNETLINK_XFRM<\/code> eine IPsec Security Association (SA) ein. Das ist eine IPsec – Konfiguration, die dem Kernel sagt, wie bestimmte Netzwerkdaten verschlüseslt und entschlüsselt werden sollen.<\/p>\n\n\n\n\n
splice()<\/code>, um Daten aus einer Datei wie \/usr\/bin\/su<\/code> direkt in einen TCP-Socket zu übertragen. Der Socket-Puffer und der Page Cache der Datei teilen sich dabei dieselbe physische Speicherseite.<\/p>\n\n\n\nTCP_ULP espintcp<\/code>, also die ESP-Verarbeitung im TCP-Stack, allerdings erst nachdem sich die Daten bereits im Socket-Puffer befinden. Der Kernel versucht nun, die Daten direkt im vorhandenen Speicher zu entschlüsseln (in-place decryption<\/em>).<\/p>\n\n\n\n\/usr\/bin\/su<\/code>. Die Datei auf der Festplatte wurde dabei nicht verändert, betroffen ist nur die im Speicher gecachte Version.<\/p>\n\n\n\nVergleich CopyFail, Dirty Frag und Fragnesia<\/h2>\n\n\n\n
\/usr\/bin\/su<\/code>, bei dem keine Race Conditions auftreten.<\/p>\n\n\n\ncrypto\/algif_aead<\/code>-Subsystem (eine Kernel-Schnittstelle für AEAD-Kryptografie wie AES-GCM) aus und ist deshalb der einzige der drei Exploits, der keinen privilegierten User-Namespace benötigt. Der Angriffsweg ist dadurch direkter als bei den anderen beiden.<\/p>\n\n\n\nCLONE_NEWUSER | CLONE_NEWNET<\/code> (Namespace-Flags zum Erstellen isolierter User- und Netzwerk-Namespaces), um innerhalb dieses isolierten Kontexts CAP_NET_ADMIN<\/code> (Administratorrechte für Netzwerkfunktionen) zu erhalten. Beide greifen anschließend Komponenten aus dem XFRM\/IPsec-Bereich an, also Teilen des Kernels, die für IPsec-Verschlüsselung und Paketverarbeitung zuständig sind.<\/p>\n\n\n\nxfrm<\/code>-ESP-Pfad (dem Kernelpfad für IPsec-ESP-Pakete) und einen weiteren in RxRPC<\/code> (einem Remote-Procedure-Call-Protokoll im Linux-Kernel). Dadurch ist der Exploit deutlich komplexer aufgebaut.<\/p>\n\n\n\nskb<\/code> (sk_buff<\/code>, die zentrale Kernel-Datenstruktur für Netzwerkpakete) das SKBFL_SHARED_FRAG<\/code>-Flag (ein Kennzeichen dafür, dass Speicherfragmente gemeinsam genutzt werden). Dadurch behandelt der Kernel beim Wechsel in den espintcp<\/code>-ULP-Modus (eine TCP-basierte ESP\/IPsec-Transporterweiterung) gepufferte File-Seiten fälschlicherweise als ESP-Chiffretext und XORt den AES-GCM-Keystream (den von AES-GCM erzeugten Verschlüsselungsstrom) direkt in diese Seiten hinein. Der Aufbau ist damit einfacher als bei Dirty Frag, die Schreibprimitive arbeitet aber trotzdem deterministisch und schreibt Byte für Byte zuverlässig in den Speicher.<\/p>\n\n\n\n\n
algif_aead<\/code> für CopyFail<\/li>\n\n\n\nesp4<\/code>, esp6<\/code> und rxrpc<\/code> für Dirty Frag und Fragnesia.<\/li>\n<\/ul>\n\n\n\nAusblick in die Zukunft<\/h2>\n\n\n\n
splice()<\/code> beziehungsweise MSG_SPLICE_PAGES<\/code> in Netzwerk- oder Kryptopfade gelangen, und schreibt dabei in Page-Cache-Seiten, bevor ausreichend geprüft wurde, ob diese Seiten überhaupt verändert werden dürfen. Bei DirtyCBC passiert das im AF_RXRPC\/RxGK-Pfad. Dabei werden AES-CBC-Daten in-place entschlüsselt, bevor die Integritätsprüfung fehlschlägt. Dadurch bleibt trotzdem eine Veränderung im Page Cache zurück. Delphos Labs beschreibt die Schwachstelle ausdrücklich als „Sibling of DirtyFrag“ und als lokale Page-Cache-Poisoning-Primitive.<\/p>\n\n\n\nsplice()<\/code>-Mechanismen, skb-Fragmente und Zero-Copy-Optimierungen miteinander interagieren.<\/p>\n\n\n\n