Fragnesia (CVE-2026-46300): Historia, Mechanizm Działania i Zalecane Środki Zaradcze

Czym jest Fragnesia? Definicja i kontekst

Fragnesia to krytyczna luka bezpieczeństwa w jądrze systemu Linux, śledzona pod identyfikatorem CVE-2026-46300 z wynikiem CVSS wynoszącym 7,8. Należy do kategorii LPE (Local Privilege Escalation) — czyli podatności umożliwiających lokalnej, nieuprzywilejowanej osobie uzyskanie pełnych uprawnień administratora systemu (roota) bez żadnej interakcji ze strony użytkownika uprzywilejowanego.

 

 

Nazwa „Fragnesia” nawiązuje do mechanizmu ataku — fragmentacji buforów sieciowych jądra (ang. fragment amnesia — dosłownie: „amnezja fragmentów”). Błąd powoduje, że jądro „zapomina”, iż dany fragment pamięci pochodzi z zewnętrznego, chronionego źródła — i traktuje go jak zwykłe dane do nadpisania.

Fragnesia została odkryta i zgłoszona przez Williama Bowlinga z zespołu badawczego V12 Security i upubliczniona 13 maja 2026 roku — zaledwie kilka dni po poprzedniej, powiązanej podatności zwanej Dirty Frag. Jest to już trzecia krytyczna luka tego samego rodzaju ujawniona w jądrze Linuksa w przeciągu zaledwie dwóch tygodni.

---

Kontekst historyczny: Rodzina luk Copy Fail, Dirty Frag i Fragnesia

Aby zrozumieć wagę Fragnesii, należy spojrzeć na nią jako element szerszej serii odkryć badacza Williama Bowlinga, które wstrząsnęły światem bezpieczeństwa systemów Linux wiosną 2026 roku.

Copy Fail (CVE-2026-31431)

Pierwsza z tej serii luk, nazwana Copy Fail, ujawniona została kilka tygodni wcześniej. Dotykała mechanizmu kopiowania danych między buforami sieciowymi i pozwalała nieuprzywilejowanemu użytkownikowi na nadpisanie zawartości chronionych plików w pamięci podręcznej stron (ang. page cache) systemu operacyjnego — bez konieczności wywoływania warunków wyścigu. Podatność umożliwiała natychmiastowe uzyskanie dostępu do powłoki roota na wszystkich głównych dystrybucjach Linuksa.

Dirty Frag (CVE-2026-43284, CVE-2026-43500)

Kilka dni po Copy Fail ten sam badacz opublikował Dirty Frag — drugą lukę w tym samym obszarze kodu (moduły esp4, esp6, rxrpc). Dirty Frag działał nieco odmiennym wektorem ataku, ale dzielił z poprzedniczką kluczową właściwość: umożliwiał deterministyczny, powtarzalny zapis do stron pamięci podręcznej plików tylko do odczytu, co w praktyce prowadziło do uzyskania roota w ciągu sekund.

Fragnesia (CVE-2026-46300)

Fragnesia to trzecia, odrębna luka — choć żyje w tej samej przestrzeni kodu co jej poprzedniczki i atakuje przez te same moduły jądra. Jej mechanizm techniczny jest jednak inny: błąd dotyczy funkcji skb_try_coalesce() w kodzie obsługi buforów sieciowych (socket buffers, skb), a nie bezpośrednio protokołu IPsec.

Publicznie dostępny proof-of-concept (PoC) exploit opublikowany przez V12 Security na platformie GitHub pozwala każdemu użytkownikowi posiadającemu dostęp do powłoki (shella) na eskalację uprawnień do roota w ciągu kilkunastu sekund.

---

Jak działa Fragnesia? Szczegóły techniczne

Trzon problemu: skb_try_coalesce() i znacznik SKBFL_SHARED_FRAG

Podatność tkwi głęboko w mechanizmie zarządzania buforami sieciowymi jądra Linux. Jądro używa struktur nazywanych socket buffers (skb) do przechowywania pakietów sieciowych w locie. Bufory te mogą zawierać zarówno dane zapisane bezpośrednio w pamięci jądra, jak i odwołania do stron page cache — czyli buforowanej w RAM reprezentacji plików z dysku.

Kluczowym znacznikiem jest flaga SKBFL_SHARED_FRAG, która informuje jądro, że dany fragment bufora jest „zewnętrznie podparty” (ang. externally backed) — czyli wskazuje na strony page cache powiązane z plikiem na dysku, a nie na prywatną pamięć jądra. Strony oznaczone tym znacznikiem powinny być traktowane jako tylko do odczytu i nigdy nie powinny być modyfikowane w miejscu.

Błąd polega na tym, że funkcja skb_try_coalesce() — odpowiedzialna za scalanie fragmentów buforów w celu optymalizacji przetwarzania — nie propagowała znacznika SKBFL_SHARED_FRAG do nowo powstałego, scalonego bufora. W efekcie jądro „traciło pamięć” o tym, że fragment pochodzi ze stron pliku.

Wektor ataku: XFRM ESP-in-TCP

Gdy już jądro traci informację o zewnętrznym pochodzeniu fragmentu, na scenę wchodzi ścieżka odbiorczą protokołu XFRM ESP-in-TCP. XFRM to framework jądra odpowiedzialny za obsługę protokołu IPsec, a ESP (Encapsulating Security Payload) to warstwa szyfrowania pakietów korzystająca z algorytmu AES-GCM.

Atakujący konfiguruje gniazdo TCP w trybie ESP-in-TCP przy użyciu warstwy górnego protokołu (ULP, Upper Layer Protocol) espintcp. Następnie do kolejki odbiorczej gniazda wstrzykuje — za pomocą wywołań systemowych splice(2) lub sendfile(2) — strony z pliku tylko do odczytu (np. /usr/bin/su). Z powodu opisanego błędu jądro nie wie już, że te strony są chronione.

Ścieżka odbiorcza XFRM ESP-in-TCP interpretuje te dane jako zaszyfrowany tekst ESP i wykonuje operację deszyfrowania AES-GCM bezpośrednio na stronach page cache — modyfikując je w miejscu. Atakujący, kontrolując klucz i IV (nonce), może precyzyjnie wybrać, jakie bajty zostaną wpisane do chronionego pliku.

Od błędu do roota: modyfikacja /usr/bin/su

Opublikowany przez V12 Security proof-of-concept skupia się na binarnym pliku /usr/bin/su — programie do zmiany użytkownika, który działa z uprawnieniami SUID i jest standardowo dostępny na wszystkich dystrybucjach Linuksa.

Exploit wstrzykuje do kopii tego pliku w page cache 192-bajtowy, niezależny od pozycji (position-independent) fragment kodu ELF (tzw. shellcode stub). Następnym razem, gdy dowolny użytkownik wywoła polecenie su, zmodyfikowana wersja pliku uruchamia się z uprawnieniami roota, a stub natychmiast otwiera uprzywilejowaną powłokę. Całość działa deterministycznie — bez warunków wyścigu, bez losowości, bez potrzeby wielokrotnych prób.

Wiz (firma należąca do Google) w swoim komunikacie opisała tę zdolność jako „deterministyczny prymityw zapisu do page cache”, podkreślając, że skuteczność eksploitu jest wyjątkowo wysoka jak na lukę w jądrze.

---

W ramach własnych testów bezpieczeństwa przeprowadziłem praktyczną weryfikację exploita Fragnesia na systemie:

• Ubuntu 24.04 LTS (Noble)
• środowisko:
  • QEMU/i440FX
  • standardowy użytkownik bez uprawnień root
  • domyślny kernel Ubuntu przed instalacją patcha

---

Przygotowanie środowiska testowego

Najpierw został doinstalowany kompilator GCC:

sudo apt install gcc -y

Następnie odblokowano możliwość używania unprivileged user namespaces:

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

To ważny element, ponieważ exploit wykorzystuje:

• user namespaces,
• network namespaces,
• mechanizmy XFRM/IPsec.

---

Pobranie i kompilacja PoC

Wykorzystany został publiczny PoC opublikowany przez V12 Security:

git clone https://github.com/v12-security/pocs.git
cd pocs/fragnesia
gcc -o exp fragnesia.c
./exp

---

Co pokazał exploit?

Podczas uruchamiania exploit:

• poprawnie utworzył user namespace,
• aktywował network namespace,
• skonfigurował xfrm_espintcp,
• uzyskał możliwość modyfikacji page cache.

Kluczowe logi:

xfrm_espintcp_state_add=1
namespace_setup_complete=1

oraz:

[+] BUG: changed requested copied byte range to desired values

To oznacza, że exploit skutecznie:

• przejął kontrolę nad ścieżką espintcp,
• wykonał page cache overwrite,
• zmodyfikował binarium /usr/bin/su.

---

Nadpisanie page cache – krytyczny moment

Exploit wykonał:

[*] smashing 192 bytes into read-only page cache

co potwierdza:

• możliwość zapisu do pamięci mapowanej jako read-only,
• obejście standardowych mechanizmów ochrony kernela.

W praktyce exploit:

• podmienił początek pliku ELF,
• wstrzyknął shellcode,
• przygotował payload do eskalacji uprawnień.

---

Finalny efekt – pełne przejęcie systemu

Po zakończeniu procesu exploit zwrócił:

# id
uid=0(root) gid=0(root) groups=0(root),65534(nogroup)

oraz:

# powned

To jednoznacznie potwierdza:

• skuteczną eskalację uprawnień,
• pełne przejęcie systemu,
• możliwość uzyskania root shell przez zwykłego użytkownika.

---

Które systemy są podatne?

Fragnesia dotyka wszystkich głównych dystrybucji Linuksa korzystających z niezałatanego jądra. Podatność jest obecna w modułach esp4 i esp6, które są standardową częścią pakietu kernela w każdej dystrybucji. Moduł rxrpc stanowi dodatkowy wektor ataku w systemach AlmaLinux 9 i 10, które mają zainstalowany pakiet kernel-modules-partner.

Poniżej zestawienie wersji jądra, w których luka zostaje usunięta w systemach z rodziny AlmaLinux/RHEL:

Dystrybucja	Wersja jądra z poprawką
AlmaLinux 8	kernel-4.18.0-553.124.2.el8_10 lub nowszy
AlmaLinux 9	kernel-5.14.0-611.54.4.el9_7 lub nowszy
AlmaLinux 10	kernel-6.12.0-124.56.2.el10_1 lub nowszy

Poprawki wydały lub testują również: Amazon Linux, CloudLinux, Debian, Gentoo, Red Hat Enterprise Linux, SUSE i Ubuntu. Patch upstream dla podsystemu skbuff jest dostępny na liście mailingowej netdev pod tematem [PATCH net] net: skbuff: preserve shared-frag marker during coalescing.

---

Zalecane środki zaradcze i metody ochrony

1. Natychmiastowe działanie: Instalacja poprawionego jądra (zalecane)

Najskuteczniejszym i jedynym trwałym rozwiązaniem jest aktualizacja jądra do wersji z poprawką i ponowne uruchomienie systemu. W przypadku AlmaLinux proces wygląda następująco:

Instalacja repozytorium testowego (jeśli poprawka nie jest jeszcze w stabilnym repo):

sudo dnf install -y almalinux-release-testing

Aktualizacja jądra:

sudo dnf update 'kernel*' --enablerepo=almalinux-testing

Restart systemu:

sudo reboot

Weryfikacja wersji jądra:

uname -r
rpm -q kernel

Dla innych dystrybucji należy skorzystać z odpowiednich menedżerów pakietów (apt, zypper, emerge) i zweryfikować dostępność łatki w oficjalnych adwizoriach bezpieczeństwa.

---

2. Tymczasowe zabezpieczenie bez restartu: Blacklisting modułów

Dla systemów, których nie można natychmiast zrestartować (np. produkcyjne środowiska wielodostępne, farmy CI/CD, hosty kontenerowe), dostępne jest skuteczne tymczasowe zabezpieczenie. Ponieważ Fragnesia atakuje przez te same moduły co Dirty Frag (esp4, esp6, rxrpc), wystarczy zablokować ich ładowanie:

sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' \
  > /etc/modprobe.d/fragnesia.conf; \
  rmmod esp4 esp6 rxrpc 2>/dev/null; true"

Polecenie to:

• Tworzy plik /etc/modprobe.d/fragnesia.conf, który zapobiega ładowaniu trzech podatnych modułów.
• Próbuje natychmiast wyładować je z pamięci (polecenie rmmod jest bezpieczne, gdyż ignoruje błędy jeśli moduł nie jest załadowany).

Aby cofnąć tę zmianę po zainstalowaniu poprawionego jądra:

sudo rm /etc/modprobe.d/fragnesia.conf

Uwaga: Nie stosuj tego zabezpieczenia, jeśli system aktywnie korzysta z tuneli IPsec (np. strongSwan, Libreswan) lub protokołu AFS/rxrpc. Wyłączenie tych modułów zablokuje wymieniony ruch sieciowy.

---

3. Czyszczenie page cache po potencjalnym ataku

Jeśli istnieje podejrzenie, że system mógł zostać zaatakowany przed zastosowaniem zabezpieczenia, należy wyczyścić pamięć podręczną stron, aby usunąć potencjalnie zmodyfikowane kopie plików binarnych z RAM:

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

Operacja ta jest bezpieczna dla działającego systemu — usuwa jedynie czyste (niezmodyfikowane przez procesy użytkownika) strony cache oraz wpisy dentry/inode. Po jej wykonaniu jądro wczyta pliki binarne ponownie bezpośrednio z dysku, eliminując wszelkie modyfikacje wprowadzone przez exploit do pamięci RAM.

---

4. Dodatkowe wzmocnienia bezpieczeństwa (hardening)

Oprócz łatki i blacklistingu modułów, specjaliści bezpieczeństwa zalecają następujące dodatkowe kroki:

Ograniczenie lokalnego dostępu do powłoki: Fragnesia wymaga posiadania lokalnego shella. Im mniej kont ma dostęp do interaktywnej powłoki na hostach produkcyjnych, tym mniejsze jest ryzyko.

Ograniczenie nieuprzywilejowanych przestrzeni nazw użytkowników: Firma Wiz wskazuje, że restrykcje AppArmor dotyczące nieuprzywilejowanych przestrzeni nazw użytkowników (ang. unprivileged user namespaces) mogą stanowić częściowe zabezpieczenie, wymuszając na atakującym stosowanie dodatkowych technik obejścia.

Wzmocnienie monitorowania: Microsoft oraz inne organizacje bezpieczeństwa zalecają zwiększenie monitorowania aktywności związanej z eskalacją uprawnień — w szczególności śledzenie wywołań su, sudo i zmian UID/EUID procesów.

Livepatch: W środowiskach, w których restart jest kosztowny operacyjnie (np. bazy danych, systemy real-time), warto rozważyć skorzystanie z rozwiązań do łatania jądra bez restartu, takich jak KernelCare, kpatch (Red Hat) czy livepatch (Ubuntu/Canonical). Technologie te pozwalają na aplikowanie poprawek do działającego jądra bez przerwy w pracy systemu.

---

Stan zagrożenia w maju 2026: Kontekst szerszy

Trzecia luka w dwa tygodnie — zmęczenie łatkami

Seria Copy Fail → Dirty Frag → Fragnesia wywołała w środowiskach administratorów systemów Linux zjawisko określane jako „patch fatigue” (zmęczenie łatkami). Konieczność przeprowadzenia trzech pilnych cykli aktualizacji jądra w ciągu dwóch tygodni — z towarzyszącymi restartami produkcyjnych serwerów — to wyjątkowy i kosztowny scenariusz.

Środowiska wielodostępne — hosty VPS, farmy CI/CD, środowiska build-farm, serwery z dostępem wielu użytkowników — są szczególnie narażone, ponieważ nieuprzywilejowany dostęp do shella jest w nich normą, a nie wyjątkiem.

Rynek exploitów zero-day

Odkrycie Fragnesii zbiegło się z doniesieniami o aktywnym handlu lukami dnia zerowego dla systemu Linux. Aktor zagrożeń o pseudonimie „berz0k” oferował na forach cyberprzestępczych exploit LPE dla Linuksa za kwotę 170 000 USD, twierdząc, że działa on na wielu głównych dystrybucjach i jest oparty na podatności klasy TOCTOU (Time-of-Check Time-of-Use). Według analizy ThreatMon exploit nie powoduje crashu systemu i ładuje payload w postaci biblioteki .so do katalogu /tmp.

Brak aktywnego wykorzystania w momencie publikacji

Zarówno Microsoft, jak i inne firmy bezpieczeństwa potwierdziły, że w chwili ujawnienia podatności nie zaobserwowano aktywnych ataków z użyciem Fragnesii w warunkach rzeczywistych (ang. in-the-wild exploitation). Fakt ten nie zmniejsza jednak pilności zastosowania poprawki — kod PoC jest publicznie dostępny, co radykalnie obniża próg wejścia dla potencjalnych atakujących.

---

Kto stoi za odkryciem? V12 Security i William Bowling

Wszystkie trzy podatności — Copy Fail, Dirty Frag i Fragnesia — zostały odkryte przez Williama Bowlinga z zespołu V12 Security. Bowling jest autorem zarówno raportów technicznych, jak i poprawek upstream przesłanych do listy mailingowej netdev (głównej listy deweloperów podsystemu sieciowego jądra Linux). Jego wkład obejmuje zarówno identyfikację błędów, jak i pisanie kodu naprawczego dla jądra — co jest przykładem wzorcowego odpowiedzialnego ujawniania podatności (responsible disclosure).

Proof-of-concept dla Fragnesii jest dostępny w repozytorium GitHub v12-security/pocs w katalogu fragnesia/ i zawiera pełny opis techniczny oraz kod exploita.

---

Krótkie podsumowanie — co zrobić teraz?

Jeśli zarządzasz systemami Linux i dotarłeś do tego miejsca artykułu, poniżej pięć najważniejszych kroków:

1. Sprawdź wersję jądra: Uruchom uname -r i porównaj z wersjami zawierającymi poprawkę dla swojej dystrybucji.
2. Zaktualizuj jądro: Zastosuj dostępne aktualizacje bezpieczeństwa i zrestartuj system.
3. Jeśli restart jest niemożliwy: Zablokuj moduły esp4, esp6 i rxrpc poleceniem opisanym w sekcji środków zaradczych.
4. Wyczyść page cache: Jeśli masz wątpliwości co do integralności systemu, wykonaj echo 3 > /proc/sys/vm/drop_caches.
5. Ogranicz dostęp lokalny: Zminimalizuj liczbę kont z dostępem do interaktywnej powłoki na hostach produkcyjnych.

---

Zasoby i źródła

• AlmaLinux Blog (13 maja 2026): Fragnesia (CVE-2026-46300): Patched kernels available in testing
• The Hacker News (14 maja 2026): New Fragnesia Linux Kernel LPE Grants Root Access via Page Cache Corruption
• GitHub V12 Security PoC: v12-security/pocs/fragnesia
• NVD Entry: CVE-2026-46300
• Red Hat Advisory: access.redhat.com/security/cve/CVE-2026-46300