CVE-2026-98432 - Linux kernel IPv4 TCP use-after-free Issue

Co się wydarzyło? — fakty ze źródeł

30 października 2026 r. Amazon Web Services opublikował biuletyn bezpieczeństwa 2026-160-AWS dotyczący podatności CVE-2026-98432 w jądrze systemu Linux. Problem występuje w mechanizmach obsługi połączeń TCP przez IPv4 i według AWS dotyczy podatnych wersji jądra od gałęzi 4.4.

Podatność należy do kategorii use-after-free (UAF). Oznacza to, że program może próbować korzystać z obszaru pamięci, który został już zwolniony. W jądrze systemu operacyjnego taki błąd może prowadzić do awarii, naruszenia integralności pamięci, ujawnienia jej zawartości, a w określonych warunkach również do zdalnego wykonania kodu.

Według AWS atakujący nie musi mieć konta na docelowym serwerze. Potencjalne wykorzystanie podatności wiąże się z odpowiednio przygotowanym ruchem IPv4 TCP, w szczególności z pakietami zawierającymi opcje nagłówka IP.

W komunikatach producentów opisano także możliwość zdalnego wykonania kodu. AWS wskazywał m.in. na demonstrację takiego scenariusza dla hostów obsługujących Multipath TCP (MPTCP). Nie oznacza to jednak, że każda instalacja Linuksa jest w identycznym stopniu narażona na przejęcie.

Dla administratorów i architektów istotne są zatem dwie kwestie: ustalenie, które systemy wykorzystują podatne jądro, oraz sprawdzenie, czy ich konfiguracja i ekspozycja sieciowa umożliwiają wykorzystanie błędu.

Na czym polega błąd?

Techniczną przyczyną CVE-2026-98432 jest warunek wyścigu (race condition) podczas równoległej obsługi żądań połączeń TCP.

Problem może wystąpić między innymi wtedy, gdy jeden proces wykonania obsługuje retransmisję żądania połączenia, a inny zwalnia strukturę pamięci przechowującą opcje IPv4. Podobny mechanizm może pojawić się podczas migracji gniazda sieciowego.

W rezultacie część kodu jądra może nadal odczytywać dane ze struktury, która została już zwolniona. To klasyczny problem zarządzania czasem życia obiektów współdzielonych przez równoległe operacje.

Opis techniczny opublikowany przez Oracle wskazuje, że poprawka wykorzystuje mechanizm RCU (Read-Copy-Update). Umożliwia on odroczenie zwolnienia pamięci do momentu, w którym wcześniejsze operacje odczytu przestaną z niej korzystać.

Z perspektywy architektonicznej jest to dobry przykład zagrożenia powstającego poniżej warstwy aplikacyjnej. Nawet prawidłowo zaprojektowana i zabezpieczona aplikacja może być narażona na skutki podatności w systemie operacyjnym, na którym działa.

Jak poważne jest zagrożenie?

Oceny producentów nie są jednakowe.

Amazon Linux przypisał podatności ocenę 8,1 w CVSS 3.1 i kategorię Important. W aktualizowanych informacjach Red Hat podatność została sklasyfikowana jako Critical, z oceną sięgającą 9,8.

Różnice te nie muszą oznaczać sprzeczności. Dostawcy uwzględniają specyfikę swoich produktów, konfigurację systemów, wymagane warunki ataku oraz możliwe skutki jego wykorzystania. Oceny mogą również zmieniać się wraz z wynikami kolejnych analiz.

Nie należy zatem traktować pojedynczej wartości CVSS jako gotowej decyzji o priorytecie aktualizacji w organizacji.

Znaczenie mają przede wszystkim wersja i konfiguracja jądra, dostępność usług TCP z sieci, zastosowane mechanizmy ochronne oraz krytyczność systemu.

Podatność umożliwiająca zdalne naruszenie bezpieczeństwa jądra zasługuje na pilną analizę. Nie jest to jednak równoznaczne z potwierdzeniem, że wszystkie serwery Linux są podatne na ten sam scenariusz ataku.

Co to oznacza dla architektury systemów?

Komentarz architektoniczny — ocena autora

Najważniejszy problem nie dotyczy wyłącznie aktualizacji jądra. Dotyczy również tego, czy organizacja potrafi jednoznacznie ustalić odpowiedzialność za bezpieczeństwo poszczególnych warstw infrastruktury.

W środowisku tradycyjnym właściciel serwera lub zespół infrastruktury zwykle odpowiada bezpośrednio za aktualizację systemu operacyjnego. W chmurze i środowiskach kontenerowych podział odpowiedzialności bywa bardziej złożony.

Maszyny wirtualne i IaaS. W przypadku samodzielnie zarządzanych instancji, na przykład Amazon EC2, klient odpowiada za aktualizację jądra. Samo udostępnienie poprawki przez dostawcę chmury nie oznacza, że została ona zastosowana na wszystkich serwerach.

Kubernetes. Kontenery współdzielą jądro systemu operacyjnego węzła. Aktualizacja obrazu aplikacji nie usuwa podatności w jądrze hosta. Konieczne może być wdrożenie nowego obrazu węzła, jego wymiana lub ponowne uruchomienie, przy zachowaniu dostępności usług.

Usługi zarządzane. Zakres odpowiedzialności zależy od modelu usługi. W niektórych przypadkach dostawca samodzielnie aktualizuje infrastrukturę. W innych klient musi zmienić wersję platformy, wymienić węzły albo wykonać dodatkowe działania.

Warstwa sieciowa. Obecność load balancera nie gwarantuje ochrony przed podatnością w jądrze serwera docelowego. AWS zwraca szczególną uwagę na konfiguracje Network Load Balancer z nasłuchem TCP, które mogą przekazywać do systemów zaplecza pakiety wraz z opcjami IPv4.

Z punktu widzenia architektury korporacyjnej oznacza to potrzebę utrzymywania nie tylko mapy aplikacji i interfejsów, ale także wiedzy o platformach wykonawczych, systemach operacyjnych, obrazach bazowych i odpowiedzialności za ich aktualizację.

Bez tych informacji nawet poprawnie działający proces zarządzania podatnościami może nie obejmować wszystkich zagrożonych komponentów.

Jak ograniczyć ryzyko?

Fakty i zalecenia producentów

AWS udostępnił aktualizacje jądra dla Amazon Linux 2 oraz Amazon Linux 2023. W przypadku samodzielnie zarządzanych instancji zaleca aktualizację pakietów i ponowne uruchomienie systemu, aby poprawione jądro zostało rzeczywiście załadowane.

Dla Amazon EKS udostępniono również zaktualizowane obrazy węzłów. Sposób postępowania zależy od tego, czy organizacja wykorzystuje własne węzły, zarządzane grupy węzłów, Karpenter czy EKS Auto Mode.

W przypadku Amazon ECS, AWS Fargate, Lambda i innych usług zarządzanych należy stosować zalecenia właściwe dla konkretnej usługi. Zakres działań wykonywanych przez klienta nie jest taki sam dla każdej z nich.

AWS opisuje także rozwiązania przejściowe, w tym wyłączenie MPTCP oraz filtrowanie pakietów IPv4 zawierających opcje nagłówka IP. Takie środki mogą ograniczać możliwość wykorzystania podatności, ale nie zastępują trwałej aktualizacji podatnego jądra.

Wprowadzenie filtrów sieciowych wymaga dodatkowo analizy wpływu na istniejący ruch i funkcjonowanie usług.

Rekomendacja architektoniczna — ocena autora

W organizacji warto przeprowadzić ocenę wpływu CVE-2026-98432 obejmującą identyfikację podatnych systemów, weryfikację ich ekspozycji sieciowej i przypisanie właścicieli odpowiedzialnych za aktualizację.

Priorytet należy nadać systemom z podatnym jądrem, obsługującym osiągalne usługi TCP, zwłaszcza gdy realizują procesy krytyczne.

Po wdrożeniu aktualizacji trzeba potwierdzić nie tylko instalację odpowiedniego pakietu, lecz także fakt uruchomienia poprawionej wersji jądra. Istotne jest również udokumentowanie systemów, których nie można zaktualizować natychmiast, wraz z przyjętymi zabezpieczeniami przejściowymi.

Wniosek dla architekta

CVE-2026-98432 przypomina, że bezpieczeństwo systemu nie kończy się na kodzie aplikacyjnym, API Gateway ani konfiguracji load balancera.

Podatność w jądrze systemu operacyjnego może wpływać na wiele aplikacji i usług jednocześnie, mimo że żadna z nich samodzielnie nie zawiera danego błędu.

Z perspektywy architektury korporacyjnej kluczowe jest więc utrzymywanie aktualnej wiedzy o zależnościach między aplikacjami, platformami wykonawczymi i infrastrukturą.

Najważniejsze pytanie brzmi: czy organizacja potrafi wskazać wszystkie systemy korzystające z podatnego komponentu, ustalić właściciela aktualizacji i potwierdzić skuteczność zastosowanej poprawki?

To właśnie zdolność do udzielenia takiej odpowiedzi — a nie samo istnienie procedury aktualizacji — decyduje o skuteczności reagowania na podobne zagrożenia.