Mitigacja identyczna jak przy Dirty Frag:
rmmod esp4 esp6 rxrpc
printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' \
> /etc/modprobe.d/fragnesia.conf
Łatka jest na liście netdev od dziś rano — jeszcze nie w mainline, jeszcze nie w żadnej dystrybucji. Łatka jest dwuliniowa. Stabilne kernele nie mają jej jeszcze.
Dodatkowe ostrzeżenie operacyjne: po uruchomieniu exploita /usr/bin/su w pamięci podręcznej kernela pozostaje zmodyfikowany i będzie otwierał powłokę roota przy każdym wywołaniu — dopóki nie wykonasz echo 1 | tee /proc/sys/vm/drop_caches lub nie zrestartujesz maszyny.
Jest jeden szczegół w tej historii który wyróżnia ją spośród "kolejny LPE w kernelu."
Hyunwoo Kim — badacz który odkrył Dirty Frag — odnotował dziś publicznie że Fragnesia jest niezamierzonym efektem ubocznym jednej z łatek naprawiających Dirty Frag. Poprawka zamknęła jeden błąd i otworzyła nowy, w tej samej przestrzeni kodu.
To jest coś więcej niż ironia. To jest sygnał o tym jak trudno jest naprawiać złożone obszary kernela bez pełnego rozumienia wszystkich konsekwencji zmiany. Łatka na skbuff.c zmieniła zachowanie przy koalescencji buforów sieciowych — i w tym samym miejscu gdzie naprawiła jeden bug zostawiła lukę dla następnego.
Mechanizm
Fragnesia atakuje ten sam podsystem co Dirty Frag — XFRM ESP-in-TCP, implementację protokołu IPsec w kernelu Linuksa. Ale to oddzielny błąd z własnym CVE: CVE-2026-46300.
Rdzeń problemu opisuje sam autor William Bowling precyzyjnie: "skb zapomina że fragment jest współdzielony podczas koalescencji." Gdy socket TCP przechodzi w tryb espintcp ULP po tym jak dane zostały już splice'owane z pliku do kolejki odbiorczej, kernel przetwarza strony pliku jako zaszyfrowany tekst ESP. Bajt AES-GCM keystreamamu jest XOR'owany bezpośrednio do strony pamięci podręcznej — strony która powinna być tylko do odczytu.
Efekt: deterministyczny zapis pojedynczego bajtu do dowolnej strony w pamięci podręcznej kernela, bez race condition. Wystarczy do nadpisania /usr/bin/su w pamięci i eskalacji do roota.
Co ważne: plik na dysku pozostaje nienaruszony. Modyfikacja dotyczy wyłącznie strony w pamięci podręcznej. Dlatego restart lub zrzucenie cache są konieczne po exploitacji — inaczej zmodyfikowany su będzie otwierał root shella przy każdym wywołaniu do czasu następnego restartu.
Trzecia w dwa tygodnie
Copy Fail (CVE-2026-31431) — 29 kwietnia. Dirty Frag (CVE-2026-43284, CVE-2026-43500) — 7 maja. Fragnesia (CVE-2026-46300) — 13 maja.
Cyber Kendra opisuje to trafnie: "Trzy krytyczne Linux LPE w dwa tygodnie to nie zbieg okoliczności — to sygnał że ten obszar kernela był za długo niezbadany."
Wszystkie trzy należą do tej samej klasy: arbitralny zapis do pamięci podręcznej strony kernela przez mechanizmy sieciowe. Dirty Pipe z 2022 roku był pierwszym reprezentantem tej klasy. Każda z kolejnych była odnaleziona przez szukanie podobnych wzorców w sąsiednich subsystemach.
To nie jest seria pechowych zbiegów okoliczności. To jest wzorzec eksploracji: gdy jeden błąd klasy jest publicznie udokumentowany, badacze — i atakujący — szukają tego samego wzorca gdzie indziej. Dirty Frag urodził Fragnesię dosłownie: przez swój patch. Ale Fragnesia mogłaby pojawić się i bez tego — ktoś po prostu szukałby tego samego wzorca w ESP-in-TCP zamiast w xfrm.
Microsoft odnotował aktywne ataki wykorzystujące wzorzec: SSH access → natychmiastowa eskalacja przez su. Ten sam wzorzec pasuje do Dirty Frag i do Fragnesia. Dla infrastruktury AI na Linuksie — serwery llama.cpp, Ollama, LMDeploy— gdzie nieuprzywilejowany dostęp przez framework jest pierwszym krokiem ataku, Fragnesia jest gotowym drugim krokiem.
Źródła
V12 Security / oss-security — pierwotne ujawnienie z kodem PoC: https://www.openwall.com/lists/oss-security/2026/05/13/3
Wiz Research — analiza techniczna mechanizmu ESP-in-TCP: https://www.wiz.io/blog/fragnesia-linux-kernel-local-privilege-escalation-via-esp-in-tcp
Phoronix — pierwsze doniesienie z kontekstem łatki netdev: https://www.phoronix.com/news/Linux-Fragnesia
Cyber Kendra — analiza trzech LPE jako sygna: https://www.cyberkendra.com/2026/05/linux-kernel-strikes-again-fragnesia-is.html















































































































Nie nowy atak, tylko naprawiony błąd. Co łatka Gemini CLI mówi o tym, że tryb –yolo w potoku CI/CD to nie jest dobry pomysł