Cztery luki w jądrze Linuksa dają uprawnienia roota

Cztery luki w jądrze Linuksa pozwalają zwykłemu użytkownikowi uruchomić kod jako root, bez żadnych specjalnych uprawnień. Najstarsze dwie siedziały w kodzie od pierwszego commita w publicznej historii jądra, czyli od 2005 roku. Zgłosił je w połowie lipca badacz Asim Manizada, a poprawki wchodziły do wydań stabilnych przez ostatnie tygodnie. Embargo uzgodnione z dystrybucjami wygasło dziś o szóstej rano czasu uniwersalnego, a razem z nim upubliczniono cztery działające dowody. Każdy kończy się powłoką roota. Właścicielowi serwera zostaje jedno pytanie: czy uname -r zwraca już numer z kompletem poprawek.

Cztery luki, cztery drogi do uprawnień roota

Wszystkie cztery błędy siedzą w sieciowej części jądra i wszystkie kończą się tak samo. Nieuprzywilejowany użytkownik lokalny uruchamia kod jako root. Różnią się tym, czego atakujący potrzebuje, żeby w ogóle dojść do błędu.

DirtyAH6 dotyczy IPsec w wersji dla protokołu IPv6. Zanim jądro policzy dane uwierzytelniające pakietu, przestawia adresy w nagłówku routingu w kolejność docelową. Funkcja, która to robi, brała liczbę adresów z jednego pola nagłówka, a licznik pozostałych skoków z drugiego. Nigdy przy tym nie sprawdzała, czy drugi mieści się w pierwszym. Pakiet z licznikiem ustawionym na 255 cofał wskaźnik o 4 064 bajty. Jądro przepisywało potem tyle samo danych spoza przydzielonego obszaru.

TUNderflow siedzi w wirtualnych kartach sieciowych TUN i TAP, z których korzystają między innymi klienty sieci VPN. Urządzenie nadrzędne może poprosić o zapas miejsca na własne nagłówki. Jądro zapisywało tę prośbę w polu, którym mierzyło potem coś innego. Urządzenie netkit z zapasem 4 096 bajtów, pracujące pod VXLAN i Open vSwitch, podawało do TUN wartość 4 160 bajtów. Licznik przekręcał się wtedy, a dane pakietu lądowały 64 bajty poza przydzielonymi 4 096 bajtami.

PPPoEject dotyczy PPPoE, czyli sposobu, w jaki wiele łączy operatorskich przenosi sesje PPP w ramkach ethernetowych. Wysyłka trzymała wskaźnik do nagłówka wtedy, gdy sterownik urządzenia miał prawo przenieść bufor i zwolnić stary. Kiedy tak się stało, jądro dopisywało sześć bajtów pod adres, którego już nie było.

DiagSpill ma w tej czwórce najniższy próg wejścia, bo jako jedyny nie wymaga ani przestrzeni nazw użytkownika, ani żadnego uprawnienia. Wystarczy, że system ma protokół SCTP i moduł diagnostyczny sctp_diag. Połączenie SCTP może mieć 65 536 adresów drugiej strony, a licznik jest szesnastobitowy i przy ostatnim wracał do zera. Narzędzie diagnostyczne rezerwowało wtedy pusty bufor i wsypywało w niego około ośmiu megabajtów.

Jak sprawdzić, czy twoje jądro jest już załatane

Polecenie jest jedno i zwraca wersję jądra, które w tej chwili pracuje:

uname -r

Autor podał numery pierwszych wydań stabilnych, w których siedzą wszystkie cztery poprawki naraz. To jest liczba do porównania.

Gałęzie spoza tej listy nie są już wspierane i poprawek w swojej linii nie dostaną. Jedynym wyjściem jest przejście na gałąź wspieraną. Osobny przypadek to linia 7.1, dla której autor odnotował brak wydania z poprawką TUNderflow.

⚠️ Sam numer bywa mylący, bo dystrybucje przenoszą poprawki do swoich starszych jąder i numerują je po swojemu. Pewniejsze jest zainstalowanie bieżących aktualizacji bezpieczeństwa i sprawdzenie komunikatu własnej dystrybucji, a nie porównywanie numeru z tabelą na oko.

Luki w jądrze Linuksa na hostingu współdzielonym i w kontenerze

Przy lukach lokalnych pojawia się odruchowa pociecha, że atakujący musi być już zalogowany. Na hostingu współdzielonym, w kontenerze i na maszynie wielu użytkowników zalogowany ktoś obcy jest stanem normalnym, a nie włamaniem. Użytkownik lokalny to także konto powłokowe u dostawcy hostingu, konto kolegi z zespołu i proces aplikacji na tej samej maszynie.

Autor pisze wprost, że wymagania tych luk nie są egzotyczne. Pokrywają standardowe moduły i ścieżki dostępne w zwykłych jądrach dystrybucyjnych. Dołożył do tego niewygodną obserwację z własnych testów: AppArmor i SELinux exploitów nie blokowały. Wyjątkiem jest Ubuntu w konfiguracjach, które blokują same nieuprzywilejowane przestrzenie nazw użytkownika.

Kontenerów dotyczy osobny akapit ogłoszenia. Wszystkie cztery potrafią uszkodzić jądro hosta z wnętrza kontenera. Pierwsze trzy wymagają wtedy odpowiednich uprawnień, DiagSpill żadnych. Autor zaznacza, że teoretycznie otwiera to drogę do ucieczki z kontenera. Sam tej ścieżki nie sprawdzał i nie ma jej w opublikowanych dowodach. Dla zespołu, który dzieli jedno jądro między kilkanaście kontenerów, to i tak wystarczający powód, żeby zaplanować restart.

Co zrobić, jeśli aktualizacja musi poczekać

Doraźne kroki są w ogłoszeniu wymienione i warto od razu znać ich granice. Wyłączenie nieuprzywilejowanych przestrzeni nazw użytkownika zdejmuje zwykłą ścieżkę do trzech pierwszych luk. Nie chroni jednak przed kontenerami i procesami, które mają odpowiednie uprawnienia. DiagSpill zostaje osiągalny mimo tej zmiany. Drugi krok to wyłączenie modułów AH6, TUN, PPPoE oraz SCTP razem z sctp_diag, jeśli nic ich u ciebie nie używa.

Ten drugi krok podchwycił na liście dyskusyjnej Hanno Böck, niezależny badacz bezpieczeństwa, i zrobił z niego szerszy wniosek. Zauważył, że same skróty w nazwach poprawek wyglądają na zestaw niestandardowych protokołów sieciowych. Ograniczanie powierzchni ataku nazwał skuteczną strategią. Jego rada jest adresowana do tych, którzy budują własne jądra: funkcji, z których się nie korzysta, można po prostu nie włączać. Na jądrze wziętym z dystrybucji odpowiednikiem jest zablokowanie ładowania modułów, których system nie używa.

Błąd z 2005 roku zniknął po jednej linijce

Cztery commity z poprawkami są publiczne i otworzyliśmy każdy z nich, żeby sprawdzić, czy opis z ogłoszenia zgadza się z kodem. Zgadza się, co do szczegółu. Najciekawsze są ich rozmiary.

Poprawka PPPoEject to jedna dodana linia w pliku drivers/net/ppp/pppoe.c. Ponownie odczytuje wskaźnik do nagłówka po tym, jak sterownik mógł przenieść bufor. DiagSpill zamknęły trzy linie w net/sctp/associola.c, odrzucające kolejny adres, gdy licznik doszedł do maksimum. Największa z czwórki, poprawka DirtyAH6, to osiemnaście dodanych linii i jedenaście usuniętych.

Oba najstarsze commity mają w nagłówku Fixes: odwołanie do Linux-2.6.12-rc2, czyli do pierwszego commita w publicznej historii repozytorium jądra. Znaczy to, że błąd jest starszy niż dostępna historia zmian, a nie że powstał dokładnie w 2005 roku. Poprawki przeszły przez ręce opiekunów podsystemów, między innymi Steffena Klasserta, Erica Dumazeta i Willema de Bruijna. Podobnie było przy luce Copy Fail z maja: roota dawał jeden skrypt, a błąd był wieloletni.

Cztery błędy znalazł zestaw narzędzi oparty na modelach językowych

W pełnym opisie autor podaje, jak do nich doszedł. Połączył grafowe śledzenie obiektów istotnych dla bezpieczeństwa z narzędziami, które pozwalają agentom rozumować o układzie pamięci w kategoriach geometrycznych. Sam nazywa tę konstrukcję harnessem i odsyła do wcześniejszych opisów, bo obie techniki ograł już przy poprzednich znaleziskach.

Ślad tej pracy został też w samym jądrze. Commit poprawiający DirtyAH6 nosi nagłówek Assisted-by: z nazwą własnego zestawu narzędzi autora, zbudowanego na mieszance modeli. Nagłówek mówi o udziale w pracy, a nie o autorstwie. Zgłoszenie, dowody działania, uzgodnienia z dystrybucjami i sam kod poprawek pozostają po stronie człowieka.

Praktyczny wniosek dotyczy tego, czego szukać dalej. Cztery błędy przeżyły w kodzie od dekady do dwóch dekad, a leżą w podsystemach, które Böck nazwał zestawem niestandardowych protokołów sieciowych. Narzędzie, które potrafi przeczesać takie ścieżki hurtem, zmienia rachunek opłacalności po obu stronach. Tę samą technikę da się skierować na kod, który wcześniej wydawał się nudny i bezpieczny.

Pierwsza Misja AI · Kodożercy

Pierwszy raz z AI? Zaczynasz od zera.

Pierwsza Misja AI to kurs dla osób bez technicznego przygotowania. Nie musisz pisać kodu ani znać żargonu. Dowiesz się, jak działa AI, jak promptować i jak korzystać z niej w pracy.

Wejdź na pokład →

Najczęstsze pytania

Czy te luki są już wykorzystywane w atakach?

Nie znaleźliśmy na to żadnego dowodu. Sprawdziliśmy katalog znanych wykorzystywanych podatności prowadzony przez amerykańską agencję CISA, w wydaniu z 18 września 2026 liczącym 1 715 pozycji. Żadnego z czterech numerów CVE w nim nie ma. Dowody działania są za to publiczne od dziś. Próg wejścia dla kogoś, kto ma już konto na maszynie, właśnie się obniżył.

Czy po aktualizacji jądra trzeba zrestartować serwer?

Tak, chyba że dostawca udostępnił łatę działającą bez restartu i obejmującą wszystkie cztery luki, a system ją załadował. Samo włączenie mechanizmu łatania na żywo nie wystarczy. Nowe jądro zaczyna pracować dopiero po ponownym uruchomieniu, więc zainstalowany pakiet sam z siebie niczego nie zmienia. Po restarcie warto ponownie wywołać uname -r i porównać numer z tabelą wyżej, zamiast zakładać, że aktualizacja się powiodła.

Podsumowanie

Komplet czterech poprawek jest w wydaniach 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.109, 6.18.50 i 7.2.4, a starsze gałęzie poza tą listą nie są już wspierane. Luki nazwane DirtyAH6, TUNderflow, PPPoEject i DiagSpill leżą w sieciowej części jądra. Każda pozwala nieuprzywilejowanemu użytkownikowi lokalnemu uruchomić kod jako root. DiagSpill wyróżnia się tym, że nie potrzebuje żadnych uprawnień ani przestrzeni nazw, wystarczy mu dostępne SCTP. Błędy przetrwały od dziesięciu do dwudziestu jeden lat, a najmniejsza z poprawek to jedna dodana linia. Zdalnego roota przez DirtyAH6 autor uzyskał tylko w laboratorium i sam nazywa taki scenariusz skrajnie trudnym. DiagSpill daje zdalnie jedynie zawieszenie, i to przy funkcjach SCTP domyślnie wyłączonych. Na maszynie, do której ma dostęp ktoś poza tobą, aktualizacja i restart są zadaniem na dziś.

Mateusz Wojdalski

Specjalista SEO i content marketingu w Devstock. Zajmuję się strategią treści, automatyzacją procesów marketingowych i wdrożeniami AI w codziennej pracy. Badam nowe narzędzia, adaptuję je do realnych zadań i piszę o tym, co faktycznie działa.