CVE-2026-98432 – krytyczna luka w jądrze Linuksa. Analiza techniczna

Zgodnie z oficjalnym biuletynem zespołu bezpieczeństwa jądra Linuksa (kernel.org), podatność CVE-2026-98432 tkwi w kodzie odpowiedzialnym za zarządzanie opcjami protokołu IP (ip_options) w trakcie trójstopniowego uzgadniania połączenia (three-way handshake) dla gniazd IPv4 TCP.

W specyficznych warunkach współbieżności dwa niezależne wątki jądra mogą jednocześnie operować na wskaźniku do tej samej struktury danych przechowującej opcje IP bez odpowiedniej synchronizacji (blokady lub mechanizmu RCU):

Wątek A uznaje strukturę za niepotrzebną lub zastępowaną i zwalnia przypisany do niej obszar pamięci w alokatorze jądra (SLAB/SLUB).
Wątek B, nieświadomy zwolnienia pamięci, nadal odwołuje się do dawnego wskaźnika, odczytując lub modyfikując znajdujące się tam dane.

Według zestawienia opublikowanego przez serwis CSO Online (które zalecamy każdorazowo skonfrontować z drzewem git na kernel.org), poprawki bezpieczeństwa trafiły do następujących wydań stabilnych i długoterminowych (LTS): 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 oraz wersji kandydującej 7.3-rc7.

Dlaczego Use-After-Free (UAF) w jądrze jest tak groźny?

W przestrzeni jądra (Ring 0) zwolniony blok pamięci nie znika – wraca do puli szybkiego alokatora obiektów o określonym rozmiarze (np. kmalloc-64 lub kmalloc-128). Jeśli atakujący zdoła w odpowiednim ułamku sekundy zmusić jądro do zaalokowania w tym samym miejscu innego obiektu, którego zawartość kontroluje (tzw. technika heap spraying lub cross-cache attack), stary „wiszący wskaźnik” (dangling pointer) zinterpretuje dane napastnika jako oryginalną strukturę systemową.

W praktyce otwiera to przed agresorem trzy etapy eskalacji:

Wyciek informacji (Info Leak): Odczytanie zawartości pamięci pozwala poznać realne adresy struktur w przestrzeni jądra, co umożliwia złamanie mechanizmu randomizacji układu przestrzeni adresowej (KASLR).
Nadpisanie wskaźników funkcji: Jeśli w podrzuconej strukturze znajdują się wskaźniki do funkcji zwrotnych (callbacks), atakujący może przekierować wykonanie kodu na gadżety ROP/JOP (Return-Oriented Programming).
Zdalne przejęcie uprawnień root: Przejęcie przepływu sterowania w kontekście jądra pozwala nadpisać struktury poświadczeń procesu (struct cred) lub wykonać polecenie powłoki z najwyższymi uprawnieniami w systemie.

Ponieważ u podstaw leży wyścig (race condition), udany atak wymaga idealnego wstrzelenia się w wąskie okno czasowe między zwolnieniem a ponownym użyciem pamięci, co w warunkach sieciowych zazwyczaj oznacza konieczność wykonania setek lub tysięcy prób.

Rola protokołu MPTCP (Multipath TCP)

Multipath TCP (MPTCP) to rozszerzenie standardu TCP pozwalające jednej sesji transportowej korzystać równolegle z wielu interfejsów i ścieżek sieciowych (np. jednoczesne łączenie przez Wi-Fi i LTE lub redundantne łącza w centrach danych).

Według opisu badaczy z Anthropic, opracowany w ich laboratorium łańcuch exploita uderza w serwery posiadające aktywne, nasłuchujące gniazdo MPTCP wystawione do sieci. Taki scenariusz jest szczególnie niebezpieczny z dwóch powodów:

Brak wymogu uwierzytelniania (Pre-Auth): Błąd wyzwalany jest już na etapie nawiązywania połączenia sieciowego, bez potrzeby posiadania lokalnego konta na serwerze i bez jakiejkolwiek interakcji użytkownika.
Bezawaryjność nieudanych prób („cichy” wyścig): W wielu lukach jądra przegrany wyścig kończy się dereferencją nieprawidłowego wskaźnika i natychmiastowym błędem Kernel Panic (restartem serwera). Tutaj, według relacji badaczy, nieudana próba wstrzelenia się w okno czasowe skutkuje jedynie cichym odrzuceniem pakietu podczas uzgadniania sesji TCP. Maszyna działa dalej stabilnie, co pozwala atakującemu ponawiać próby w pętli bez wywoływania alarmów dostępności u administratora.

Co pokazał eksperyment Anthropic i gdzie zachować sceptycyzm?

W raporcie z 27 października Anthropic poinformował, że po otrzymaniu wstępnego zadania od badacza, ich niepublikowany model AI samodzielnie przeanalizował problem i skonstruował działający exploit:

Około 48 minut zajęło modelowi uzyskanie wycieku wskaźnika jądra (obejście KASLR).
Kolejne 5 minut wystarczyło na przekucie tego w pełne wykonanie polecenia powłoki (łącznie 53 minuty pracy modelu).
Ze względów bezpieczeństwa firma nie upubliczniła kodu źródłowego exploita ani dokładnej konfiguracji maszyny testowej.

Spojrzenie krytyczne branży

Jako redakcja zawsze oddzielamy twardą inżynierię od komunikacji PR-owej firm rozwijających AI:

Brak niezależnej weryfikacji procesu odkrycia: Eksperci z firmy Black Duck słusznie zauważyli, że o ile same łatki w kodzie Linuksa są publiczne i każdy może przeanalizować błąd w obsłudze opcji IP, o tyle twierdzenia o stopniu autonomii modelu podczas tworzenia exploita opierają się wyłącznie na słowach samego Anthropic.
Wpływ nowoczesnych mitygacji: Przedstawiciele Black Duck podkreślili również, że w niezależnych testach skuteczność modeli językowych drastycznie spada, gdy środowisko docelowe ma włączone pełne spektrum zabezpieczeń (zaawansowane izolacje pamięci podręcznej SLUB, sprzętowe mechanizmy typu CFI/PAC czy rygorystyczny sandboxing). Przywołano przy tym dane firmy VulnCheck, według których zaledwie około 1,3% luk powiązanych z odkryciami AI zostało kiedykolwiek potwierdzonych jako realnie wykorzystane w atakach.
Kwestia powiązania CVE: Serwis Cyber Security News zwrócił uwagę, że bezpośrednie powiązanie identyfikatora CVE-2026-98432 z opisanym przez Anthropic łańcuchem RCE przez MPTCP pochodzi z publikacji samego zespołu badawczego AI, a nie z pierwotnego, zwięzłego komunikatu deweloperów jądra.
Brak ataków w terenie: Do 30 października 2026 r. żaden zespół CERT ani dostawca telemetrii EDR nie odnotował prób wykorzystania tej luki w rzeczywistych atakach.

Co zrobić jako administrator: instrukcja krok po kroku

Zinwentaryzuj flotę serwerów i sprawdź bieżące jądro:Bashuname -r
Weryfikuj wersję pakietu dystrybucyjnego, nie sam numer z uname: Pamiętaj, że dystrybucje korporacyjne (Debian, RHEL, Ubuntu, SUSE) stosują tzw. backporting – przenoszą samą łatkę do starszego numeru jądra (np. 5.14.0-xxx.el9), aby nie psuć kompatybilności ABI. Sprawdź dokładną wersję zainstalowanego pakietu (dpkg -l | grep linux-image lub rpm -qa | grep kernel) i porównaj ją z tabelą CVE swojego dostawcy (Debian Security Tracker, Ubuntu Security Notices, Red Hat CVE Database).
Zastosuj aktualizację lub Livepatching: Zainstaluj zaktualizowane pakiety jądra i zaplanuj okno serwisowe na restart maszyn. W środowiskach o krytycznej dostępności użyj mechanizmów łatania w locie (Canonical Livepatch, Red Hat kpatch, Oracle Ksplice), o ile dostawca wydał dla tej luki moduł livepatch.
Sprawdź i ogranicz powierzchnię MPTCP (jako środek tymczasowy): Jeżeli Twoje serwery nie korzystają z Multipath TCP, zweryfikuj status protokołu i aktywne gniazda:Bash# Sprawdzenie, czy MPTCP jest włączone w przestrzeni nazw sieciowych sysctl net.mptcp.enabled # Sprawdzenie aktywnych połączeń i gniazd MPTCP ss -M Tymczasowe wyłączenie (sysctl -w net.mptcp.enabled=0 oraz wpis w /etc/sysctl.d/) zamyka opisaną przez Anthropic ścieżkę ataku, ale nie traktuj tego jako substytutu aktualizacji jądra – sam błąd dotyczy obsługi opcji IPv4 TCP i może być potencjalnie osiągalny innymi ścieżkami.
Wymuś segmentację sieci i filtrowanie na brzegu: Ogranicz dostęp do portów TCP z niezaufanych sieci za pomocą reguł nftables / iptables lub sprzętowych zapór sieciowych, szczególnie tam, gdzie usługi nie muszą być wystawione bezpośrednio do publicznego internetu.
Monitoruj anomalie systemowe: Zwracaj uwagę na niewyjaśnione ślady w buforze komunikatów jądra (dmesg -T, journalctl -k) wskazujące na uszkodzenia struktur SLUB/SLAB (general protection fault, BUG: KASAN w środowiskach testowych) oraz niespodziewane procesy potomne uruchamiane z UID 0.

Ciekawostka…

Gdy tylko pojawił się biuletyn dotyczący CVE-2026-98432, sprawdziliśmy nasze własne środowiska serwerowe (oparte głównie o Debiana 12/13 oraz Ubuntu LTS) pod kątem realnej ekspozycji MPTCP. I tu wychodzi na jaw detal, o którym łatwo zapomnieć, czytając prasowe nagłówki: w wielu nowoczesnych jądrach Linuksa parametr net.mptcp.enabled jest domyślnie ustawiony na 1! Oznacza to, że podsystem MPTCP w jądrze jest aktywny. Dlaczego więc nie każdy serwer w internecie jest od razu bezbronny na scenariusz opisany przez Anthropic?

Ponieważ samo włączenie net.mptcp.enabled=1 nie sprawia automatycznie, że klasyczny Nginx, OpenSSH czy HAProxy zaczyna nasłuchiwać jako gniazdo MPTCP (IPPROTO_MPTCP) – aplikacja musi jawnie utworzyć takie gniazdo lub zostać uruchomiona przez wrapper typu mptcpize run. W naszej infrastrukturze polecenie ss -M zwróciło pustą listę na wszystkich węzłach frontowych, mimo że sysctl pokazywał wartość 1. Mimo to na wszystkich serwerach brzegowych zdecydowaliśmy się wyzerować net.mptcp.enabled=0 do czasu wdrożenia docelowych paczek jądra (na Debianie łatki weszły błyskawicznie, podczas gdy na kilku instancjach Ubuntu musieliśmy poczekać na publikację binariów w repozytorium -security). Wnioski? Nie panikujcie z powodu marketingu wokół „AI piszącego exploity w 53 minuty”, ale potraktujcie ten przypadek jako test sprawności Waszego potoku Ansible/Terraform – jeśli załatanie jądra na 50 maszynach zajmuje Wam tydzień ustaleń z biznesem, to właśnie ten tydzień jest Waszą prawdziwą luką bezpieczeństwa.