Es ist ein Exploit für GRO Frag – eine lokale Privilegienerweiterungsschwachstelle im Linux-Kernel, die mit der Verarbeitung von GRO und zero-copy skb im Netzwerk-Stack zusammenhängt. Das genaue Datum der anfänglichen Entdeckung in öffentlichen Materialien ist nicht angegeben. Anhand öffentlicher Spuren können zwei Daten identifiziert werden: Der Fix wurde in der Mailingliste netdev diskutiert am 20. Mai 2026, wo diese Schwachstelle bereits als geeignet zur Überschreibung des Page Cache beschrieben wurde, und ein öffentlicher PoC wurde auf GitHub Gist am 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 es nicht privilegierten Prozessen, neue Instanzen von io_uring zu erstellen, es sei denn, sie sind in der erlaubten Gruppe io_uring_group enthalten; mit dem Wert -1 haben nur Prozesse mit CAP_SYS_ADMIN Zugriff. Dies ist eine Minderung, kein umfassender Fix für die Schwachstelle.
Das Problem liegt in der Funktion skb_gro_receive(): Beim Zusammenführen von GRO-Paketen konnte der Kernel Fragmente aus zero-copy skb in ein anderes skb ohne ordnungsgemäße Überprüfung des Zustands von zero-copy und des SKBFL_MANAGED_FRAG_REFS-Flags übertragen. Infolgedessen konnten Speicherseiten, auf die das ursprüngliche skb keine separaten Referenzen hielt, inkorrekt freigegeben werden, was zu use-after-free führte. Im Patch wird ausdrücklich darauf hingewiesen, dass eine solche Situation zu UAF führen kann und dass die gefundene Variante zur Überschreibung 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 Netzschnittstelle veth. Im Kommentar zum Code wird angegeben, dass die Kern-Versionen betroffen sind Linux 6.0+, die Ausnutzung ist für nicht privilegierte Benutzer möglich, erfordert jedoch ein zugängliches io_uring; als Patch wurde genannt Commits 4db79a322db8 mit der Änderung „net: gro: don’t merge zcopy skbs“.
In Bezug auf die Auswirkungen gehört GRO Frag zur gleichen gefährlichen Fehlerklasse wie Copy Fail und Dirty Frag: Ein Angreifer mit lokalem nicht privilegierten Zugang kann Daten im Page Cache ändern, d. h. im Speicher, ohne dass der Datei auf der Festplatte eine verpflichtende Modifikation erforderlich ist. Solche Fehler sind besonders unangenehm, da sie die Grenze zwischen einer „nur-Lese“-Datei und dem tatsächlichen Inhalt betreffen, den der Kernel und Prozesse bei nachfolgenden Zugriffen sehen. Elastic hat früher diese Klasse als praktischen Weg beschrieben, um durch Page-Cache-Korrosion Root zu erhalten.
Zum Zeitpunkt der Veröffentlichung war anscheinend noch kein separater CVE-Identifikator für GRO Frag zugewiesen. Als vorübergehende Maßnahmen sollten Administratoren in Erwägung ziehen, den Kernel auf eine Version mit einem Fix zu aktualisieren sowie allgemeine Risikominderungsmaßnahmen für solche LPE anzuwenden: Beschränkung unprivilegierter User-Namensräume, wo es möglich ist, Überwachung der Verwendung von io_uring und die Überwachung verdächtiger Ketten im Zusammenhang mit lokaler Privilegieneskalation. Für verwandte Copy Fail/DirtyFrag-Angriffe empfiehlt Elastic zudem, Patchen mit der Erkennung niederstufiger Exploit-Primitiven zu kombinieren.
Niederstufige Exploit-Primitiven sind nicht der ‚bereitgestellte Hack‘ selbst, sondern grundlegende technische Techniken, aus denen ein Exploit besteht.
Im Kontext von GRO Frag könnte dies bedeuten, nicht das Vorhandensein eines ‚Benutzers, der root geworden ist‘ zu erkennen, sondern zu versuchen, einzelne verdächtige Aktionen zu bemerken, die der Exploit auf dem Weg zur Privilegieneskalation verwendet.
Quelle: linux.org.ru
