SCTPhantom CVE-2026-64564: 18-letni błąd Linuksa prowadził do roota

SCTPhantom, oznaczona CVE-2026-64564, to luka use-after-free w implementacji SCTP jądra Linux. Kod wprowadzony około 2008 roku błędnie obsługiwał usuwanie adresu w mechanizmie Dynamic Address Reconfiguration. Lokalny napastnik, który mógł komunikować się z gniazdem SCTP, był w stanie doprowadzić do użycia zwolnionej struktury transportowej i przejść od korupcji pamięci kernela do uprawnień root.

Badacze Tencent Zhuque Lab opisali skuteczne podniesienie uprawnień na testowanych konfiguracjach Debian 13, Ubuntu 24.04, Rocky Linux 9, RHEL 9 i OpenCloudOS. Pokazali też ucieczkę z kontenera w środowisku, w którym proces mógł dotrzeć do podatnej ścieżki SCTP hosta. To nie znaczy, że każdy kontener automatycznie jest podatny: konieczne są właściwe namespace’y, moduły, możliwości i dostęp do protokołu.

Gdzie pojawia się use-after-free

SCTP może utrzymywać wiele adresów dla jednego skojarzenia. Rozszerzenie dynamicznej rekonfiguracji pozwala dodawać i usuwać te adresy podczas trwania połączenia. Jądro musi wtedy poprawnie powiązać adres z obiektem transportu, sprawdzić, czy można go usunąć, wycofać referencje i nie dopuścić do dalszego użycia wskaźnika.

W podatnej ścieżce adres weryfikowany przed operacją DEL-IP nie zawsze odpowiadał transportowi wybranemu później przez stos sieciowy. Obiekt mógł zostać usunięty, mimo że inna część obsługi nadal zachowywała do niego wskaźnik. Kolejne zdarzenie korzystało ze zwolnionej pamięci. Jeżeli atakujący odpowiednio ułoży alokacje sterty, nowy obiekt może zająć to samo miejsce i zmienić dane interpretowane przez kernel.

Rekord CVE-2026-64564 klasyfikuje błąd w podsystemie sieciowym Linuksa. Poprawka synchronizuje obiekt podlegający walidacji z transportem używanym przez dalszą logikę oraz zamyka ścieżkę do nieaktualnej referencji.

Dlaczego kontenery nie są granicą bezpieczeństwa kernela

Kontener współdzieli jądro z hostem. Network namespace izoluje widok interfejsów i gniazd, ale nie tworzy osobnego kernela. Jeżeli proces może wywołać podatny kod sieciowy hosta, memory-safety bug działa poniżej granicy namespace’u. O skuteczności ataku decydują więc capabilities, polityki seccomp, dostępność modułu SCTP, konfiguracja sieci i wersja uruchomionego kernela.

Nie należy jednak wyłączać SCTP w ciemno w sieciach telekomunikacyjnych, systemach sygnalizacyjnych lub rozwiązaniach, które rzeczywiście go potrzebują. Najpierw inwentaryzacja, potem poprawka i kontrolowane ograniczenie powierzchni.

Naprawa i działania wykrywające

1. Zainstaluj poprawiony kernel. Wskazane stabilne wydania obejmują 7.1.6, 6.18.42, 6.12.101 i 6.6.148; dla dystrybucji kieruj się jej backportem, nie samym numerem upstream.
2. Uruchom host ponownie i zweryfikuj uname -r; obecność pakietu na dysku nie oznacza, że poprawiony kernel pracuje.
3. Ustal, gdzie moduł sctp jest załadowany oraz które usługi, pody i kontenery tworzą gniazda SCTP.
4. Gdzie protokół jest zbędny, zablokuj automatyczne ładowanie modułu i ogranicz odpowiednie rodziny gniazd polityką seccomp lub runtime’u.
5. Usuń niepotrzebne capabilities sieciowe, nie uruchamiaj kontenerów uprzywilejowanych i ogranicz dostęp do host network.
6. Monitoruj awarie, ostrzeżenia KASAN, Oops, nietypowe ładowanie modułu SCTP i procesy tworzące gniazda tego protokołu.
7. Po podejrzeniu eksploatacji traktuj host oraz wszystkie współdzielone sekrety jako potencjalnie przejęte; ponowne uruchomienie kontenera nie usuwa dostępu root w kernelu.

Fakty i analiza Breachroad

Publiczne informacje potwierdzają use-after-free, lokalny charakter ataku, obecność błędu od wielu lat oraz poprawki w gałęziach stabilnych. Wyniki badaczy na kilku dystrybucjach pokazują wykonalność, lecz nie dowodzą identycznej eksploatowalności w każdej konfiguracji kontenerowej. Priorytet dla hostów wielodostępnych jest wnioskiem Breachroad wynikającym ze wspólnego kernela i większej liczby nieufnych procesów.

Szkolenia z bezpieczeństwa infrastruktury pomagają zespołom rozumieć granice izolacji, a audyt chmury i kontenerów łączy wersje kernela z realną ekspozycją protokołów i uprawnieniami workloadów.