W jądrze Linux ujawniono nową podatność na lokalne podwyższenie uprawnień, która otrzymała nazwę Fragnesia i identyfikator CVE-2026-46300. Problem dotyczy tej samej kategorii ataków na pamięć podręczną strony, co niedawno omawiane Copy Fail i Dirty Frag, ale nie jest powtórną publikacją starego błędu: chodzi o oddzielny defekt w kodzie XFRM ESP-in-TCP.
Podatność odkrył badacz William Bowling z zespołu V12 Security. Z danych opublikowanego opisu wynika, że Fragnesia umożliwia nieuprzywilejowanemu lokalnemu użytkownikowi modyfikację zawartości plików, które są dostępne tylko do odczytu, w pamięci podręcznej strony i w ten sposób wykonywanie kodu z uprawnieniami roota. W przeciwieństwie do wielu starych exploitów LPE, atak nie wymaga wyścigu i jest opisywany przez badaczy jako deterministyczny.
Technicznie problem polega na tym, że podczas łączenia buforów sieciowych, jądro mogło zgubić oznaczenie, że fragment danych jest 'wspólny' i powiązany z zewnętrzną stroną pamięci, w tym z pamięcią podręczną strony. W proponowanej poprawce opisano to jako błąd w skb_try_coalesce(): podczas przenoszenia paged fragments z jednego sk_buff do drugiego nie zachowywano flagi SKBFL_SHARED_FRAG. W efekcie późniejszy kod ESP mógł błędnie uznać bufor za bezpieczny do modyfikacji.
Praktyczny efekt polega na tym, że dane, które wcześniej umieszczono w kolejce TCP z pliku, po przełączeniu gniazda w tryb espintcp mogły być przetwarzane przez jądro jako zaszyfrowany tekst ESP. Podczas deszyfrowania AES-GCM bajty były zmieniane bezpośrednio w stronie pamięci podręcznej powiązanej z plikiem. Nie zmienia to pliku na dysku, ale zmienia jego reprezentację w pamięci, aż do wyciśnięcia strony z pamięci podręcznej.
W opublikowanej demonstracji ataku jako cel wykorzystano /usr/bin/su: exploit zmodyfikował pierwsze bajty pliku binarnego w pamięci podręcznej strony, a następnie uruchomił zmodyfikowaną w pamięci kopię, uzyskując powłokę z uprawnieniami roota. Oryginalny plik na dysku pozostał nietknięty, co czyni problem szczególnie trudnym do diagnozy: ślady eksploatacji mogą zniknąć po oczyszczeniu pamięci podręcznej strony lub ponownym uruchomieniu.
Fragnesia pojawiła się mniej niż tydzień po Dirty Frag. W V12 podkreślają, że to osobny błąd w tym samym wektorskim ataku — ESP/XFRM, a nie ponowne nazwanie już naprawionej luki. Phoronix również zauważa, że w momencie publikacji dostępny był proof-of-concept, a poprawka stanowiła niewielką łatkę do net/core/skbuff.c, która nie natychmiast trafiła do głównych oddziałów jądra.
Canonical przyznała CVE-2026-46300 wysoki priorytet dla Ubuntu, wskazując jako przyczynę „trivial local privilege escalation”. Na stronie Ubuntu Security dla dotkniętych jąder na dzień aktualizacji 13 maja widniał status „Needs evaluation”, a w uwagach zaznaczone było, że problem występuje również w module ESP jądra i może być tymczasowo łagodzony w ten sam sposób, co Dirty Frag.
Debian Security Tracker w momencie sprawdzania oznaczał jako podatne jądra w gałęziach bullseye, bookworm, trixie, forky i sid; dla pakietu linux w unstable nie wskazano jeszcze wersji z poprawką.
Tymczasowa metoda ochrony pozostaje taka sama, jak dla Dirty Frag: wyłączyć ładowanie modułów esp4, esp6 i rxrpc, jeśli nie są potrzebne systemowi. Może to zakłócić działanie tuneli IPsec na węzłach, gdzie używane są kernel ESP, strongSwan, Libreswan lub podobne konfiguracje, dlatego na bramach VPN taką metodę należy stosować tylko po ocenie konsekwencji.
Przykład tymczasowego złagodzenia dla administratorów:
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
Jeśli istnieje podejrzenie, że system mógł być już zaatakowany, sama blokada modułów jest niewystarczająca: ponieważ publiczna demonstracja zmienia plik wykonywalny w page cache, administratorzy zalecają wyczyszczenie cache'a stron lub ponowne uruchomienie systemu po zastosowaniu środków ochrony. CloudLinux wyraźnie wskazuje, że po eksploatacji /usr/bin/su może pozostawać zmodyfikowany w pamięci aż do wyparcia odpowiednich stron.
Aby usunąć tymczasową regułę po zainstalowaniu poprawionego jądra, można usunąć utworzony plik:
sudo rm /etc/modprobe.d/dirtyfrag.conf
Główna rekomendacja pozostaje standardowa: zainstalować poprawione jądro od swojego dystrybucji i ponownie uruchomić system. Do aktualizacji największe ryzyko mają serwery wielodostępowe, CI-runery, shared hosting, kontenerowe farmy build i wszelkie maszyny, gdzie nieuprzywilejowani lub częściowo zaufani użytkownicy mogą wykonywać lokalny kod.
Źródło: linux.org.ru
