W publicznym dostępie pojawił się exploit dla GRO Frag — lokalnej podatności na podniesienie uprawnień w jądrze Linux, związanej z obsługą GRO i zero-copy skb w stosie sieciowym. Dokładna data pierwotnego odkrycia w materiałach publicznych nie została wskazana. Według dostępnych informacji można ustalić dwie daty: poprawka była omawiana na liście dyskusyjnej netdev 20 maja 2026 roku, gdzie ta podatność była już opisana jako nadająca się do przechwytywania page cache, a publiczny PoC został umieszczony na GitHub Gist 22 maja 2026 roku.
Jako tymczasowe rozwiązanie przed zainstalowaniem poprawionego jądra można ograniczyć wektor ataku za pomocą sysctl: kernel.io_uring_disabled=1. Taki tryb zabrania tworzenia nowych instancji io_uring przez nieuprzywilejowane procesy, chyba że są one w dozwolonej grupie io_uring_group; przy wartości grupy -1 dostęp mają tylko procesy z CAP_SYS_ADMIN. To jest tylko mitygacja, a nie pełna naprawa tej podatności.
Problem tkwi w funkcji skb_gro_receive(): podczas łączenia pakietów GRO jądro mogło przenosić fragmenty z zero-copy skb do innego skb bez odpowiedniego sprawdzenia stanu zero-copy i flagi SKBFL_MANAGED_FRAG_REFS. W rezultacie strony pamięci, na które pierwotny skb nie trzymał oddzielnych referencji, mogły być zwolnione niepoprawnie, co prowadziło do use-after-free. W łatce wyraźnie zaznaczono, że taka sytuacja może prowadzić do UAF, a także że znaleziony wariant był zdolny do przechwytywania page cache.
Opublikowany PoC opisuje podatność jako LPE przez GRO managed-frag UAF z wykorzystaniem io_uring SEND_ZC i wirtualnego interfejsu sieciowego veth. W komentarzu do kodu wskazano, że dotknięte są jądra Linux 6.0+, eksploatacja jest możliwa przez nieuprzywilejowanego użytkownika, ale wymaga dostępnego io_uring; jako poprawkę wymieniono commitu 4db79a322db8 z modyfikacją „net: gro: nie łącz z zcopy skbs”.
W konsekwencjach GRO Frag mieści się w tej samej niebezpiecznej klasie błędów, co Copy Fail i Dirty Frag: atakujący z lokalnym nieuprzywilejowanym dostępem uzyskuje możliwość zmiany danych w page cache, czyli w pamięci, bez obowiązkowej modyfikacji pliku na dysku. Takie błędy są szczególnie uciążliwe, ponieważ dotyczą granicy między „tylko do odczytu” pliku a faktyczną zawartością, którą widzi jądro i procesy przy kolejnych odwołaniach. Elastic wcześniej opisała tę klasę jako praktyczny sposób uzyskania root przez uszkodzenie page-cache.
Na moment publikacji oddzielny identyfikator CVE dla GRO Frag, według dostępnych informacji, jeszcze nie został przydzielony. Jako środki tymczasowe administratorzy powinni skupić się na aktualizacji jądra do wersji z poprawką, a także na ogólnych środkach zmniejszających ryzyko dla takich LPE: ograniczenie nieuprzywilejowanych przestrzeni nazw użytkowników wszędzie tam, gdzie to możliwe, kontrola użycia io_uring oraz monitorowanie podejrzanych łańcuchów związanych z lokalną eskalacją przywilejów. W przypadku pokrewnych ataków Copy Fail/DirtyFrag, Elastic również zaleca łączenie łatania z wykrywaniem niskopoziomowych prymitywów wykorzystania podatności.
Niskopoziomowe prymitywy wykorzystania to nie sam "gotowy atak", a podstawowe techniczne techniki, z których buduje się exploit.
W kontekście GRO Frag może to oznaczać nie wykrywanie już gotowego faktu „użytkownik stał się rootem”, ale próbę zauważenia osobnych podejrzanych działań, które exploit wykorzystuje w drodze do podwyższenia przywilejów.
Źródło: linux.org.ru
