Im Linux-Kernel wurde eine neue Schwachstelle für lokale Privilegien eskalieren entdeckt, die den Namen Fragnesia und die Kennung CVE-2026-46300. Das Problem gehört zur gleichen Angriffsgruppe auf den Page Cache wie die jüngst diskutierten Copy Fail und Dirty Frag, ist jedoch keine Wiederveröffentlichung eines alten Fehlers: Es handelt sich um einen spezifischen Defekt im Code von XFRM ESP-in-TCP.
. Die Schwachstelle wurde von dem Forscher William Bowling aus dem Team V12 Security. Laut der veröffentlichten Beschreibung ermöglicht Fragnesia einem unprivilegierten lokalen Benutzer, den Inhalt von nur lesbaren Dateien im Page Cache zu ändern und dadurch Code mit Root-Rechten auszuführen. Im Gegensatz zu vielen alten LPE-Exploits erfordert der Angriff kein Rennen und wird von den Forschern als deterministisch beschrieben.
Das technische Problem hängt damit zusammen, dass beim Zusammenführen von Netzwerkpuffern der Kernel das Merkmal verlieren konnte, dass ein Datenfragment "gemeinsam" ist und mit einer externen Speicherseite, einschließlich des Page Caches, verbunden ist. Im vorgeschlagenen Patch wird dies als Fehler in skb_try_coalesce() beschrieben: Beim Übertragen von paginierten Fragmenten von einem sk_buff zu einem anderen wurde das Flag SKBFL_SHARED_FRAG nicht beibehalten. Infolgedessen konnte späterer ESP-Code fälschlicherweise annehmen, dass der Puffer sicher zur Modifikation war.
Die praktische Auswirkung besteht darin, dass Daten, die zuvor aus einer Datei in die TCP-Warteschlange eingefügt wurden, nach dem Wechsel des Sockets in den Modus espintcp vom Kernel als ESP-verschlüsselter Text behandelt werden konnten. Bei der Entschlüsselung von AES-GCM wurden die Bytes direkt im Page Cache, der mit der Datei verbunden ist, geändert. Dies ändert die Datei auf der Festplatte nicht, beeinflusst jedoch ihre Darstellung im Speicher, bis die Seite aus dem Cache verdrängt wird.
In der veröffentlichten Angriffsdemonstration wurde /usr/bin/su als Ziel verwendet: Der Exploit modifizierte die ersten Bytes der Binärdatei im Page-Cache und startete dann eine geänderte Kopie im Arbeitsspeicher, wodurch eine Shell mit Root-Rechten erlangt wurde. Die Originaldatei auf der Festplatte blieb dabei unverändert, was das Problem besonders unangenehm für die Diagnose macht: Spuren des Exploits können nach dem Leeren des Page-Caches oder einem Neustart verschwinden.
Fragnesia tauchte weniger als eine Woche nach Dirty Frag auf. In V12 wird betont, dass es sich um einen separaten Fehler an derselben Angriffsoberfläche – ESP/XFRM – handelt, und nicht um eine Umbenennung einer bereits behobenen Verwundbarkeit. Phoronix weist ebenfalls darauf hin, dass zum Zeitpunkt der Veröffentlichung ein Proof-of-Concept verfügbar war und der Fix ein kleiner Patch für net/core/skbuff.c war, der noch nicht sofort in die Hauptzweige des Kernels aufgenommen wurde.
Canonical hat CVE-2026-46300 hohe Priorität für Ubuntu zugewiesen und als Grund "triviale lokale Privilegieneskalation" angegeben. Auf der Ubuntu-Sicherheitsseite für die betroffenen Kernel wurde zum Zeitpunkt des Updates am 13. Mai der Status "Needs evaluation" angegeben, und in einer Anmerkung wird separat erwähnt, dass das Problem auch im ESP-Modul des Kernels vorhanden ist und vorübergehend auf die gleiche Weise wie bei Dirty Frag gemildert werden kann.
Debian Security Tracker Zum Zeitpunkt der Überprüfung wurden die Kerne in den Zweigen bullseye, bookworm, trixie, forky und sid als anfällig markiert; für das Paket linux in unstable wurde noch keine feste Version angegeben.
Die vorläufige Sicherheitsmaßnahme bleibt dieselbe wie bei Dirty Frag: das Laden von Modulen esp4, esp6 und rxrpc zu deaktivieren, wenn sie für das System nicht erforderlich sind. Dies kann die Funktion von IPsec-Tunneln auf Knoten beeinträchtigen, an denen kernel ESP, strongSwan, Libreswan oder ähnliche Konfigurationen verwendet werden, daher sollte diese Maßnahme auf VPN-Gateways nur nach einer Folgenbewertung angewendet werden.
Beispiel für vorübergehende Minderung für Administratoren:
sudo sh -c "printf 'install esp4 /bin/falseninstall esp6 /bin/falseninstall rxrpc /bin/falsen' > /etc/modprobe.d/dirtyfrag.conf" sudo rmmod esp4 esp6 rxrpc 2>/dev/null || true
Wenn der Verdacht besteht, dass das System bereits angegriffen worden sein könnte, reicht eine Blockade der Module nicht aus: Da die öffentliche Demonstration die ausführbare Datei genau im Page Cache ändert, empfehlen Administratoren, den Seiten-Cache zu leeren oder das System nach Anwendung der Schutzmaßnahmen neu zu starten. CloudLinux weist ausdrücklich darauf hin, dass nach der Ausnutzung /usr/bin/su in память измененным оставаться может до вытеснения соответствующих страниц.
Um die temporäre Regel nach der Installation des korrigierten Kernels zu entfernen, kann die erstellte Datei gelöscht werden:
sudo rm /etc/modprobe.d/dirtyfrag.conf
Die wichtigste Empfehlung bleibt unverändert: Installieren Sie den korrigierten Kernel von Ihrer Distribution und starten Sie das System neu. Vor dem Update besteht das höchste Risiko bei Mehrbenutzerservern, CI-Runnern, Shared Hosting, Container-Build-Farmen und allen Maschinen, auf denen nicht privilegierte oder teilweise vertrauenswürdige Benutzer lokalen Code ausführen können.
Quelle: linux.org.ru
