Dirty Frag reiht sich in dieselbe Fehlerklasse ein wie Dirty Pipe und Copy Fail, erweitert sie aber. Laut Kim handelt es sich um einen deterministischen Logikfehler, der nicht von einem Zeitfenster abhängt – damit entfällt die sonst übliche Race Condition, der Kernel stürzt bei einem misslungenen Versuch nicht ab, und die Erfolgsquote ist sehr hoch.
Bislang existiert keine CVE-Kennung. Nach Angaben zur Veröffentlichung wurde das Embargo gebrochen, nachdem ein unbeteiligter Dritter detaillierte Informationen sowie den Exploit für die xfrm-ESP Page-Cache Write-Schwachstelle öffentlich publiziert hatte.
Zur Herkunft der Fehler: Die xfrm-ESP-Schwachstelle wurzelt im IPSec- bzw. xfrm-Subsystem und wurde laut Kim durch einen Quellcode-Commit vom Januar 2017 eingeführt. Sie liefert Angreifern – wie schon Copy Fail – ein 4-Byte-Schreibprimitiv und überschreibt eine kleine Menge im Page-Cache des Kernels. Bemerkenswert ist, dass derselbe Commit vom 17. Januar 2017 auch Ursache eines weiteren Pufferüberlaufs (CVE-2022-27666, CVSS-Wert 7.8) war. Die RxRPC-Schwachstelle wurde dagegen im Juni 2023 eingeführt.
Die Verkettung beider Varianten gleicht ihre jeweiligen blinden Flecken aus. Der ESP-Exploit setzt voraus, dass der nicht privilegierte Nutzer einen Namespace anlegt – ein Schritt, den Ubuntu über AppArmor blockiert; dort lässt sich xfrm-ESP Page-Cache Write nicht auslösen. Genau hier greift der zweite Exploit: RxRPC Page-Cache Write benötigt keine Berechtigung zum Anlegen eines Namespace, allerdings ist das Modul rxrpc.ko in den meisten Distributionen nicht enthalten. Der Standard-Build von RHEL 10.1 etwa liefert rxrpc.ko nicht mit, auf Ubuntu hingegen wird das Modul standardmäßig geladen. In Umgebungen, die das Anlegen von User-Namespaces erlauben, läuft der ESP-Exploit; auf Ubuntu, wo dies blockiert ist, aber rxrpc.ko gebaut wird, funktioniert der RxRPC-Exploit.
CloudLinx verortet den Fehler in einem Beratungsschreiben im „ESP-in-UDP MSG_SPLICE_PAGES no-COW fast path", erreichbar über die XFRM-User-Netlink-Schnittstelle. AlmaLinux präzisiert, der Fehler liege in den In-Place-Entschlüsselungspfaden von esp4, esp6 und rxrpc: Trägt ein Socket-Puffer ausgelagerte Fragmente, die nicht privat dem Kernel gehören – etwa per splice(2), sendfile(2) oder MSG_SPLICE_PAGES angehängte Pipe-Pages –, entschlüsselt der Empfangspfad direkt über diese extern hinterlegten Seiten und legt damit Klartext offen oder beschädigt ihn, auf den ein nicht privilegierter Prozess weiterhin eine Referenz hält.
Solange keine Patches verfügbar sind, wird empfohlen, die Module esp4, esp6 und rxrpc per Blocklist am Laden zu hindern. Anders als Copy Fail lässt sich Dirty Frag zudem unabhängig davon ausnutzen, ob das Kernel-Modul algif_aead aktiviert ist. Selbst auf Systemen, auf denen die bekannte Copy-Fail-Gegenmaßnahme – das Sperren von algif_aead – angewendet wurde, bleibt der Kernel laut Kim für Dirty Frag verwundbar.