Jedna luka, pięć różnych ocen: wyścig w stosie TCP Linuksa, co do którego nikt się nie zgadza

CVE-2026-98432 to podatność typu race condition w kodzie, którego jądro Linuksa używa do nawiązywania nowych połączeń IPv4 TCP. Może doprowadzić do odczytu przez jądro pamięci już zwolnionej, czyli błędu typu use-after-free.

Luka jest osiągalna zdalnie, nie wymaga uwierzytelnienia i publicznie wykazano, że pozwala uzyskać zdalne wykonanie kodu z uprawnieniami roota w co najmniej jednej konfiguracji.

Trzy rzeczy sprawiają, że ten przypadek wart jest uważnej lektury, a nie tylko spojrzenia na punktację.

Ocena istotności jest realnie sporna. Zespół ds. CVE jądra Linuksa przyznaje 9,8. Strona CVE Red Hat podaje 5,9 i Moderate. Własny plik doradczy Red Hat w formacie maszynowym podaje 8,1 i Important. Oracle i SUSE podają 8,1. Amazon podaje 7,0. To nie są różnice wynikające z zaokrągleń.

Dwie największe dystrybucje nie mają poprawki. Na 29 października Ubuntu i Red Hat Enterprise Linux nie wydały poprawionego jądra i żadna z firm nie podała terminu. Debian, Oracle Linux, SUSE i Amazon Linux dostarczyły poprawki przynajmniej dla części swoich jąder.

Zademonstrowany exploit napisał model sztucznej inteligencji. Anthropic opublikował 27 października informację, że jego model Claude napisał exploit pozwalający uzyskać wykonanie poleceń jako root na serwerach Linux z nasłuchem multipath TCP.

Należy powiedzieć wprost, że Anthropic jest twórcą modelu, który przygotował ten materiał, a badacz wskazany w poprawce jądra, Xinyang Ge, pracuje w tej firmie. Ten fragment warto czytać z taką świadomością.

Co się wydarzyło

Na czym polega błąd

Wyścig zachodzi podczas uzgadniania połączenia TCP. Gdy połączenie zostaje zestawione, jądro przekazuje opcje IP zapisane przy oczekującym żądaniu do nowego gniazda bez ich kopiowania. Jeśli to gniazdo zostanie zniszczone, podczas gdy inny procesor wciąż używa tych opcji do odpowiedzi na ponowione żądanie połączenia, jądro odczytuje zwolnioną pamięć.

IPv6 nie jest podatne, ponieważ dla połączeń IPv6 jądro kopiuje opcje. To problem wyłącznie IPv4.

Błąd wprowadzono w Linuksie 4.4, czyli istnieje od lat. Deweloperzy jądra zastosowali poprawkę 5 października, dziesięć dni przed publikacją CVE. Poprawka sprawia, że jądro czeka, aż pozostałe procesory zakończą odczyt opcji, zanim je zwolni.

Dlaczego oceny się różnią

To najbardziej użyteczna część tej historii dla każdego, kto zajmuje się priorytetyzacją, bo spór dotyczy jednej konkretnej rzeczy.

Wszystkie strony oceniają lukę identycznie we wszystkich metrykach CVSS poza złożonością ataku.

• Zespół ds. CVE jądra Linuksa ocenia złożoność jako niską, przyjmując, że napastnik wysyła żądanie połączenia TCP zawierające opcje IPv4 Record Route lub Timestamp, a następnie ponawia je, by wygrać wyścig. Obie strony wyścigu są wywoływane przez napastnika. Przy takim odczytaniu błąd może zwrócić napastnikowi sąsiadującą pamięć jądra, uszkodzić pamięć jądra albo spowodować awarię systemu. Stąd 9,8.

• Red Hat, Oracle i SUSE oceniają złożoność jako wysoką, bo wygranie wyścigu jest trudne. Stąd 8,1.

• Publiczna strona CVE Red Hata idzie dalej, przyznając 5,9 i stwierdzając, że najbardziej prawdopodobnym skutkiem jest awaria jądra, uszkodzenie pamięci jest możliwe teoretycznie, a „nie wykazano wpływu na poufność ani integralność".

To ostatnie stanowisko trudniej utrzymać po publikacji Anthropic, a własne rejestry Red Hata zdają się to odzwierciedlać. System śledzenia błędów firmy podniósł 29 października istotność zgłoszenia ze średniej na wysoką, a plik doradczy podaje Important i 8,1 z wysokim wpływem na poufność i integralność, podczas gdy publiczna strona CVE tego samego dnia nadal pokazywała Moderate i 5,9.

Na 28 października National Vulnerability Database nie dodała własnej oceny i wyświetlała punktację zespołu ds. CVE jądra, czyli 9,8. Strona Ubuntu pokazuje to samo.

Co robi exploit

Opis opublikowany przez Anthropic 27 października przedstawia dwa etapy.

Etap pierwszy: wyścig powoduje, że jądro odsyła napastnikowi dodatkowe bajty. Gdy jedna z tych odpowiedzi zawiera adres z pamięci jądra, obchodzi to KASLR, czyli randomizację adresów pamięci jądra.

Etap drugi: ten sam błąd przepełnia bufor i nadpisuje wskaźnik wywołania zwrotnego adresem ładunku, który napastnik wcześniej umieścił w pamięci jądra. Gdy jądro wywołuje ten wskaźnik, ładunek wykonuje wybrane polecenie powłoki jako root.

Czasy z testu Anthropic: 48 minut na wyciek adresu jądra, a następnie kolejne 5 minut do wykonania polecenia. Przegrany wyścig kończy się niepowodzeniem tylko tej jednej próby połączenia i nie powoduje awarii systemu, więc napastnik może próbować w nieskończoność, nie wzbudzając alarmu.

Publikacja Anthropic nie zawiera kodu exploita, wersji jądra ani testowanej konfiguracji.

Kwestia MPTCP

To ma znaczenie przy ustalaniu, czy jesteś narażony.

Exploit Anthropic dający uprawnienia roota był wymierzony w serwery z nasłuchem multipath TCP (MPTCP). Ani wpis CVE, ani poprawka jądra nie wspominają o MPTCP. Powiązanie tej funkcji z exploitem pochodzi wyłącznie z publikacji Anthropic, która nie mówi, czy serwery bez nasłuchu MPTCP można przejąć w ten sam sposób.

W Linuksie aplikacja musi sama zażądać MPTCP przy otwieraniu gniazda. I tu pułapka: od Go 1.24 programy w Go domyślnie żądają MPTCP dla gniazd, na których nasłuchują. Bardzo wiele osób ma więc nasłuch MPTCP, nie podjąwszy takiej decyzji.

Zespół bezpieczeństwa Go opublikował wytyczne 29 października. Są wyjątkowo szczere i warto oddać je treściowo, a nie luźno sparafrazować:

• Ustawienie GODEBUG=multipathtcp=0 w środowisku programu wyłącza domyślne MPTCP w czasie działania. Dodanie godebug multipathtcp=0 do pliku go.mod głównego modułu robi to samo na etapie budowania. Kod wywołujący SetMultipathTCP nadpisuje oba te ustawienia.

• Zespół nazywa wyłączanie MPTCP program po programie kruchym środkiem zaradczym. Jeden pozostawiony nasłuch MPTCP nadal naraża system, a samo podejście zakłada, że każdy działający exploit zależy od MPTCP.

• Co najważniejsze: zespół stwierdza, że błąd nie jest specyficzny dla MPTCP, że systemy bez nasłuchów MPTCP mogą być podatne na podobne ataki, a właściwym rozwiązaniem jest aktualizacja jądra.

Kto ma poprawkę

Ubuntu wskazuje również swoje jądra chmurowe, FIPS i czasu rzeczywistego jako podatne lub będące w trakcie prac.

Jeśli budujesz własne jądro, poprawka znajduje się w wersjach 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 i 7.3. Zespół ds. CVE jądra zaleca przejście na najnowsze jądro stabilne i zaznacza, że społeczność jądra nie wspiera wybiórczego przenoszenia pojedynczych poprawek.

Red Hat informuje, że żaden dostępny środek zaradczy nie spełnia jego kryteriów łatwości wdrożenia, przydatności dla większości instalacji i stabilności. Komunikaty pozostałych dystrybucji również żadnego nie wskazują.

Brak ataków w praktyce

Na 29 października żaden komunikat dostawcy, wpis CVE ani publikacja Anthropic nie informowały o atakach wykorzystujących tę lukę. Nie figurowała ona w kopii katalogu znanych wykorzystywanych podatności CISA zaktualizowanej 28 października.

Dlaczego to ma znaczenie

Spór o punktację nie jest akademicki, bo decyduje o tym, czy w ogóle zareagujesz. Zespół priorytetyzujący na podstawie publicznej oceny Red Hata 5,9 odłoży tę sprawę na później. Zespół opierający się na ocenie 9,8 potraktuje ją jak sytuację awaryjną. Obydwa czytają oficjalne źródła. To praktyczny koszt polegania na punktacji jednego dostawcy.

Zademonstrowany exploit waży więcej niż ocena teoretyczna. Publiczna strona Red Hata mówi, że nie wykazano wpływu na poufność ani integralność. Opublikowano tymczasem opis exploita osiągającego wykonanie poleceń jako root. Właściwą reakcją jest ponowna ocena, a wewnętrzne rejestry Red Hata sugerują, że to się dzieje.

Ubuntu i RHEL razem stanowią ogromną część produkcyjnego Linuksa. Brak poprawionego jądra, brak terminu i brak akceptowalnego środka zaradczego to najpoważniejszy fakt w tej sprawie i jednocześnie ten, na który czytelnik ma najmniejszy wpływ.

MPTCP jest domyślnie włączone dla nasłuchów w Go. To szczegół, który najłatwiej przeoczyć. Jeśli wdrażasz usługi w Go zbudowane w wersji 1.24 lub nowszej, możesz wystawiać nasłuch MPTCP, nie podjąwszy takiej decyzji.

Nie traktuj wyłączenia MPTCP jako rozwiązania. Zespół Go wprost ostrzega, że błąd nie jest specyficzny dla MPTCP i że systemy bez takich nasłuchów mogą być podatne na podobne ataki.

Exploity pisane przez AI są już elementem krajobrazu ujawnień. Praktyczną konsekwencją jest skracanie się okna między ujawnieniem błędu a istnieniem działającego exploita. To ten sam wzorzec, który Amazon opisywał przy ujawnieniu PHP2Shell, i staje się on normą, a nie wyjątkiem.

Kogo to dotyczy

• Każdego systemu Linux z jądrem od wersji 4.4 wzwyż, który nie otrzymał poprawki i wystawia usługę IPv4 TCP.

• Użytkowników Ubuntu i RHEL, którzy obecnie nie mają dostępnego poprawionego jądra.

• Operatorów usług w Go zbudowanych w wersji 1.24 lub nowszej, domyślnie żądających MPTCP dla gniazd nasłuchujących.

• Środowisk chmurowych i kontenerowych, gdzie jedno niezałatane jądro hosta leży pod wieloma obciążeniami.

• Użytkowników jąder chmurowych, FIPS i czasu rzeczywistego Ubuntu, wskazanych jako podatne lub w trakcie prac.

• Usług działających wyłącznie na IPv6, które ten konkretny wyścig nie dotyczy.

Co powinny zrobić organizacje

Łataj tam, gdzie możesz

1. Zainstaluj poprawione jądro tam, gdzie Twoja dystrybucja je wydała. Debian, Oracle Linux, SUSE Micro i openSUSE Leap oraz część Amazon Linux 2023 udostępniły pakiety.

2. Jeśli budujesz własne jądro, przejdź na poprawioną wersję stabilną i zastosuj się do zalecenia zespołu ds. CVE jądra, by brać najnowsze wydanie stabilne zamiast przenosić pojedynczą poprawkę.

3. Śledź codziennie komunikaty Ubuntu i Red Hat. Żadna z firm nie podała terminu, więc wymaga to monitorowania, a nie wpisu w kalendarzu.

W czasie oczekiwania

4. Zinwentaryzuj hosty wystawiające usługi IPv4 TCP do niezaufanych sieci. To Twoja populacja narażona i prawdopodobnie jest większa, niż zakładasz.

5. Zidentyfikuj usługi w Go zbudowane w wersji 1.24 lub nowszej. Mogą nasłuchiwać z domyślnie włączonym MPTCP.

6. Traktuj wyłączenie MPTCP jako ograniczenie ryzyka, a nie usunięcie problemu. GODEBUG=multipathtcp=0 w czasie działania lub godebug multipathtcp=0 w go.mod na etapie budowania pomogą, ale SetMultipathTCP w kodzie nadpisuje oba, jeden pominięty nasłuch zostawia Cię narażonym, a zespół Go mówi, że błąd nie jest specyficzny dla MPTCP.

7. Ogranicz ekspozycję sieciową niezałatanych hostów tam, gdzie usługa nie musi być dostępna z niezaufanych sieci.

Priorytetyzacja i nadzór

8. Nie priorytetyzuj tej sprawy na podstawie oceny jednego dostawcy. Sprawdź wpis CVE opublikowany przez zespół jądra, stronę swojej dystrybucji i plik doradczy dostawcy, który w przypadku Red Hat obecnie nie zgadza się z jego własną stroną CVE.

9. Zweryfikuj ponownie oceny ustalone przed 27 października. Publikacja działającego exploita zmienia dane wejściowe, a istotność w rejestrach co najmniej jednego dostawcy już się przesunęła.

10. Obserwuj dodanie do katalogu KEV. Na 28 października luka tam nie figurowała. Jeśli się pojawi, automatycznie zmienią się federalne terminy usunięcia oraz większość wewnętrznych polityk eskalacji.

Wykrywanie, którego tu niewiele

11. Nie opublikowano żadnych wytycznych detekcyjnych. Nieudane próby wygrania wyścigu nie powodują awarii systemu, więc napastnik może ponawiać je w nieskończoność bez widocznych sygnałów. Monitoruj niewyjaśnioną niestabilność jądra i traktuj nieoczekiwaną aktywność procesów z uprawnieniami roota na hostach wystawionych do internetu jako wartą zbadania.

Podsumowanie

Race condition wprowadzony do jądra Linuksa w wersji 4.4, poprawiony w źródłach 5 października, oceniony na od 5,9 do 9,8 w zależności od tego, kogo pytasz, bez dostępnej poprawki od dwóch najszerzej wdrożonych dystrybucji korporacyjnych i bez środka zaradczego, który Red Hat uznałby za akceptowalny. Taka jest sytuacja i jest niewygodna.

Lekcja: ocena CVSS jest opinią, a w tym przypadku opinii jest pięć. Cały rozrzut sprowadza się do jednej metryki, czyli złożoności ataku, i do jednego pytania: jak trudno wygrać ten wyścig. Zespół jądra mówi, że napastnik kontroluje obie jego strony. Publiczna strona Red Hata mówi, że to trudne i że niczego nie wykazano. Opublikowany exploit dający uprawnienia roota jest dowodem odnoszącym się wprost do tego pytania, a procesy priorytetyzacji, które przyjęły ocenę 20 października i przeszły dalej, do tej sprawy nie wrócą.

Druga lekcja dotyczy odstępu między poprawką w źródłach a poprawką u Ciebie. Jądro naprawiono 5 października. Debian i Oracle wydały pakiety 16 października. Trzy tygodnie później użytkownicy Ubuntu i RHEL wciąż nie mają czego zainstalować. Naprawione w źródłach nie znaczy naprawione u Ciebie, a w odległości między tymi dwoma stanami mieszka realne ryzyko.

Dwie rzeczy warte zrobienia dziś: spisz każdy host wystawiający usługę IPv4 TCP do niezaufanej sieci oraz sprawdź, czy któraś z Twoich usług w Go została zbudowana w wersji 1.24 lub nowszej.