Im Linux-Kernel wurde eine weitere Schwachstelle für eine lokale Privilegienausübung entdeckt, die den Namen Fragnesia und die Kennung CVE-2026-46300. Das Problem gehört zur gleichen Angriffsart auf den Page Cache wie die kürzlich diskutierten Copy Fail und Dirty Frag, ist jedoch keine Wiederholung eines alten Fehlers: es handelt sich um einen separaten Defekt im Code. 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 nicht privilegierten lokalen Benutzer das Ändern des Inhalts von nur lesbaren Dateien im Page Cache und somit die Ausführung von Code mit Root-Rechten. Im Gegensatz zu vielen alten LPE-Exploits erfordert der Angriff kein Timing und wird von Forschern als deterministisch beschrieben.
Technisch gesehen hängt das Problem damit zusammen, dass beim Zusammenführen von Netzwerkpuffern der Kernel das Kennzeichen verlieren konnte, dass ein Datenfragment „gemeinsam“ ist und mit einer externen Speicherseite, einschließlich des Page Cache, verbunden ist. Im vorgeschlagenen Patch wird dies als Fehler in skb_try_coalesce() beschrieben: Beim Übertragen von gepufferten Fragmenten von einem sk_buff zu einem anderen wurde das Flag SKBFL_SHARED_FRAG nicht beibehalten. Infolgedessen konnte der spätere ESP-Code fälschlicherweise annehmen, dass der Puffer sicher für Änderungen ist.
Die praktische Auswirkung besteht darin, dass Daten, die zuvor in die TCP-Warteschlange aus einer Datei eingegeben wurden, nach dem Umschalten des Sockets in den ESP-in-TCP-Modus vom Kernel als ESP-Verschlüsselungstext verarbeitet werden konnten. Bei der Entschlüsselung von AES-GCM wurden Bytes direkt im Page Cache verändert, der mit der Datei verbunden ist. Das ändert die Datei auf der Festplatte nicht, verändert jedoch ihre Darstellung im Speicher, bis die Seite aus dem Cache verdrängt wird.
In der veröffentlichten Demonstration des Angriffs wurde als Ziel /usr/bin/su verwendet: der Exploit modifizierte die ersten Bytes der Binärdatei im Page Cache und führte dann die im Speicher geänderte Kopie aus, um eine Shell mit Root-Rechten zu erhalten. Die ursprüngliche Datei auf der Festplatte blieb dabei unverändert, was das Problem besonders schwierig zu diagnostizieren macht: Spuren der Ausnutzung können nach dem Leeren des Page Cache oder einem Neustart verschwinden.
Fragnesia tauchte weniger als eine Woche nach Dirty Frag auf. In V12 wird hervorgehoben, dass es sich um einen separaten Fehler an der gleichen Angriffsoberfläche — ESP/XFRM — handelt, und nicht um eine Umbenennung einer bereits behobenen Schwachstelle. Phoronix stellt auch fest, dass zum Zeitpunkt der Veröffentlichung ein Proof-of-Concept verfügbar war und der Fix aus einem kleinen Patch für net/core/skbuff.c bestand, der noch nicht in die Hauptzweige des Kernels integriert war.
Canonical hat CVE-2026-46300 hohe Priorität für Ubuntu zugewiesen und den Grund als „triviale lokale Privilegieneskalation“ angegeben. Auf der Ubuntu-Sicherheitsseite für die betroffenen Kernel war zum Zeitpunkt des Updates am 13. Mai der Status „Bedarf an Bewertung“ angegeben, und es wurde gesondert vermerkt, dass das Problem auch im ESP-Modul des Kernels vorhanden ist und vorübergehend auf die gleiche Weise gemildert werden kann wie Dirty Frag.
Debian Security Tracker markierte zum Zeitpunkt der Überprüfung die Kernel in den Branches bullseye, bookworm, trixie, forky und sid als verwundbar; für das Paket linux in unstable war noch keine fixe Version angegeben.
Die vorübergehende Schutzmaßnahme bleibt die gleiche wie bei Dirty Frag: deaktivieren Sie das Laden der Module esp4, esp6 und rxrpc, falls sie für das System nicht benötigt werden. 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 Bewertung der Konsequenzen angewendet werden.
Beispiel für eine vorübergehende Milderung 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, ist eine bloße Blockierung der Module nicht ausreichend: Da die öffentliche Demonstration die ausführbare Datei direkt im Page Cache modifiziert, empfehlen Administratoren, den Page Cache zu leeren oder das System nach der Umsetzung der Schutzmaßnahmen neu zu starten. CloudLinux weist ausdrücklich darauf hin, dass nach der Ausnutzung /usr/bin/su bis zum Austausch der entsprechenden Seiten im Speicher verändert bleiben kann.
Um die vorübergehende Regel nach der Installation des behobenen Kernels zu entfernen, kann die erstellte Datei gelöscht werden:
sudo rm /etc/modprobe.d/dirtyfrag.conf
Die wichtigste Empfehlung bleibt standardmäßig: Installieren Sie den behobenen Kernel von Ihrer Distribution und starten Sie das System neu. Bis zum Update bergen besonders Mehrbenutzerserver, CI-Runner, Shared Hosting, Container-Build-Farmen und alle Maschinen, auf denen nicht privilegierte oder teilweise vertrauenswürdige Benutzer lokalen Code ausführen können, die größten Risiken.
Quelle: linux.org.ru
