Ein Exploit für GRO Frag ist öffentlich aufgetaucht, der eine lokale Privilegienerhöhung im Linux-Kernel betrifft, die mit der Verarbeitung von GRO und zero-copy skb im Netzwerkstack zusammenhängt. Das genaue Datum der ursprünglichen Entdeckung ist in den öffentlichen Materialien nicht angegeben.Anhand öffentlicher Hinweise können zwei Daten festgestellt werden: Die Behebung wurde in der Mailingliste netdev diskutiert. 20. Mai 2026, wo diese Schwachstelle bereits als geeignet für das Überschreiben des Page-Caches beschrieben wurde, und ein öffentlicher PoC wurde am GitHub Gist 22. Mai 2026.
. Als vorübergehende Maßnahme bis zur Installation des korrigierten Kernels kann der Angriffsvektor über sysctl eingeschränkt werden: kernel.io_uring_disabled=1. Dieser Modus verbietet die Erstellung neuer io_uring-Instanzen durch unprivilegierte Prozesse, es sei denn, sie sind in der erlaubten Gruppe io_uring_group enthalten; bei einem Gruppenwert von -1 bleibt der Zugriff nur Prozessen mit CAP_SYS_ADMIN vorbehalten. Dies ist eine Mitigation, kein vollständiger Fix der Schwachstelle.
Das Problem liegt in der Funktion skb_gro_receive(): Bei der Zusammenführung von GRO-Paketen konnte der Kernel Fragmente aus zero-copy skb in ein anderes skb übertragen, ohne den Zustand von zero-copy und das Zeichen SKBFL_MANAGED_FRAG_REFS korrekt zu überprüfen. Infolgedessen konnten Speicherseiten, auf die das ursprüngliche skb keine separaten Referenzen hielt, unsachgemäß freigegeben werden, was zu einem Use-After-Free führte. Der Patch weist ausdrücklich darauf hin, dass eine solche Situation zu UAF führen kann und dass die gefundene Variante für das Überschreiben des Page-Cache geeignet war.
Der veröffentlichte PoC beschreibt die Schwachstelle als LPE über GRO managed-frag UAF unter Verwendung von io_uring SEND_ZC und der virtuellen Netzwerkschnittstelle veth. Im Codekommentar wird erwähnt, dass die Kernels betroffen sind Linux 6.0+, die Ausnutzung ist einem nicht privilegierten Benutzer möglich, erfordert jedoch ein verfügbares io_uring; als Patch wird genannt Commit 4db79a322db8 mit der Änderung „net: gro: don’t merge zcopy skbs“.
Die Folgen von GRO Frag fallen in die gleiche gefährliche Fehlerkategorie wie Copy Fail und Dirty Frag: Ein Angreifer mit lokalem, unprivilegiertem Zugang kann Daten im Page-Cache, also im Arbeitsspeicher, ändern, ohne die Datei auf der Festplatte modifizieren zu müssen. Solche Fehler sind besonders unangenehm, da sie die Grenze zwischen einer "Nur-Lese"-Datei und dem tatsächlichen Inhalt berühren, den der Kernel und Prozesse bei nachfolgenden Zugriffen sehen. Elastic beschrieb zuvor diese Klasse als praktischen Weg, um Root-Zugriff durch Page-Cache-Korruption zu erlangen.
Zum Zeitpunkt der Veröffentlichung war laut verfügbaren Berichten noch keine separate CVE-ID für GRO Frag vergeben. Als vorläufige Maßnahme sollten Administratoren ein Kernel-Update auf eine Patch-Version in Betracht ziehen sowie allgemeine Risikominderungsmaßnahmen für derartige lokale Privilegien-Eskalationen: Einschränkung nicht privilegierter User-Namensräume, wo immer möglich, Kontrolle der Nutzung von io_uring und Überwachung verdächtiger Ketten, die mit der lokalen Eskalation von Privilegien in Verbindung stehen. Für verwandte Copy Fail/DirtyFrag-Angriffe empfiehlt Elastic ebenfalls, das Patchen mit der Erkennung von niederwertigen Exploit-Primitiven zu kombinieren.
Niederwertige Exploit-Primitiven sind nicht der eigentliche ‚fertige Hack‘, sondern grundlegende technische Techniken, aus denen ein Exploit aufgebaut wird.
Im Kontext von GRO Frag könnte dies bedeuten, nicht das bereits vollständige Ereignis ‚Benutzer wurde root‘ zu erkennen, sondern zu versuchen, einzelne verdächtige Aktivitäten zu bemerken, die der Exploit auf dem Weg zur Privilegienerhöhung verwendet.
Quelle: linux.org.ru
