Linux dostał 9,3 na 10. Niestety, to ocena dziury w zabezpieczeniach

Maszyny wirtualne mają odizolować uruchomione na nich aplikacje i systemy od reszty infrastruktury. Krytyczna luka w jądrze Linuksa podważa jednak to zabezpieczenie. Błąd nazwany PwnEscape pozwala atakującemu z poziomu maszyny wirtualnej próbować wydostać się poza jej granice i uzyskać dostęp do pamięci hosta. Podatność otrzymała ocenę 9,3 na 10, a poprawka nie dotarła jeszcze do wszystkich zagrożonych systemów.

Podatność oznaczona jako CVE-2026-99999 dotyczy stosu sieciowego jądra Linuksa, a nie bezpośrednio samego mechanizmu wirtualizacji KVM. To istotna różnica, bo KVM umożliwia uruchamianie maszyn wirtualnych na jednym fizycznym serwerze. Dzięki izolacji każda z nich powinna działać w odseparowanym środowisku, bez swobodnego dostępu do pamięci i zasobów systemu gospodarza.

PwnEscape może tę barierę osłabić. Atakujący potrzebuje dostępu do maszyny wirtualnej, z której wysyła specjalnie spreparowane pakiety IPv4. Według opisu badacza atak nie wymaga dodatkowych uprawnień ani interakcji użytkownika, a jego przeprowadzenie nie jest szczególnie skomplikowane. Potencjalne konsekwencje są poważne, zwłaszcza dla dostawców usług chmurowych. Jeśli atakujący wydostanie się z maszyny wirtualnej na hosta, zagrożone mogą być również inne środowiska działające na tym samym serwerze.

Aby zainfekować cały host, atakujący musi jedynie wysłać nieprawidłowe pakiety sieciowe IPv4 z wnętrza maszyny wirtualnej – większość programów zazwyczaj ma dostęp do sieci. Nie są wymagane żadne uprawnienia ani interakcja użytkownika, a złożoność ataku jest niska. Ocena ważności błędu wynosi 9,3 na 10. Poprawka została zaakceptowana już 8 października i włączona do głównego kodu jądra Linuksa 14 października. Różne dystrybucje Linuksa nie udostępniły jej jeszcze swoim użytkownikom.

Jak działa exploit?

Aby maszyny wirtualne miały dostęp do otwartego internetu, jądro hosta musi przetworzyć ich ruch. Błąd tkwi w sposobie, w jaki Linux obsługuje pakiety sieciowe. Każdy pakiet sieciowy ma nagłówek zawierający informacje takie jak miejsce przeznaczenia, rozmiar, protokół, którego używa i inne. Pakiety przesyłane są przez internet z dołączoną sumą kontrolną, która pozwala sprawdzić, czy ładunek dotarł bez uszkodzeń.

Jednak maszyny wirtualne często wysyłają pakiety bez kompletnej sumy kontrolnej, pozostawiając jej obliczenie jądru hosta, oszczędzając w ten sposób zasoby obliczeniowe. Zamiast tego maszyny wirtualne dołączają metadane opisujące, co obliczyć i gdzie zapisać wynik. Implementacja protokołu IPv4 w jądrze hosta korzysta z funkcji pomocniczej o nazwie skb_checksum_help w celu obliczenia sumy kontrolnej i zapisania jej w odpowiednim miejscu pakietu. Okazuje się, że jądro nie weryfikuje metadanych wystarczająco dobrze, a atakujący mogą uszkodzić pakiety, przemycając wprowadzające w błąd metadane.

Yibelo zademonstrował exploit polegający na wysłaniu bardzo małego pakietu o długości zaledwie 28 bajtów, z czego 20 bajtów to nagłówek IPv4. Jednak metadane nakazują jądru zapisanie sumy kontrolnej w niewłaściwym miejscu – nadpisując pole długości nagłówka oryginalnego. Po tej operacji nagłówek 20-bajtowy traktowany jest jako dłuższy nagłówek 60-bajtowy, podczas gdy cały pakiet nadal ma długość zaledwie 28 bajtów. Jądro wykonało sprawdzenie tylko raz, przed zmianą pakietu, a następnie nadal ufało jego wcześniejszym wynikom.

Teraz następuje uszkodzenie: przed odesłaniem pakietu do atakującego jądro odczytuje go, ufając nowemu rozmiarowi jego nagłówka – kopie 60 bajtów, a ponad połowa tych danych pochodzi z sąsiedniej pamięci. „Kolejne 32 bajty nie wchodziły w skład logicznych, liniowych danych pakietu” – wyjaśnia badacz w szczegółowym opisie.

Prowadzi to do „powtarzalnego, kontrolowanego przez atakującego ujawniania pamięci hosta”, co naraża na ujawnienie poufnych informacji, do których goście nigdy nie powinni mieć dostępu.

Badacz twierdzi, że problem ten nie jest wyłącznie kwestią odczytu i może zostać jeszcze bardziej rozszerzony – w ich warunkach laboratoryjnych można go przekształcić w kontrolowane zmiany w pamięci jądra. „Wykorzystując obserwacje pamięci hosta i starannie kontrolowane zachowanie alokacji, zademonstrowaliśmy wybrane 64-bajtowe zapisy hosta i jądra” – czytamy w raporcie.

Raport nie zawiera szczegółów na temat tego, „co było potrzebne, aby przejść od kontroli pierwotnej do kontroli hosta”.

now that the KVM escape details are out (https://t.co/5QFoYyonbX)… if you’re wondering how i managed to rediscover it in under 2 hours after seeing the vercel bounty screenshot: i gave openai’s gpt-5.6-cyber (daybreak red) access to a devbox to experiment and explore different directions for 1.5 hours. then i spotted that the word after “guest-controlled” in the screenshot wasn’t properly redacted. those 3 dots gave away “virtio”. might seem like a small hint, but i passed it to my agent, and it got excited and found the vulnerability in 30 minutes. :)) opsec lesson right there.

— Adel Ka (@0x4D31) October 15, 2026

Problem dotyczy nie tylko KVM

Znaczenie PwnEscape wykracza poza pojedynczy mechanizm wirtualizacji. Źródłem błędu jest kod sieciowy jądra Linuksa, wykorzystywany w wielu środowiskach. Podatność może więc mieć znaczenie dla różnych konfiguracji serwerów i platform opartych na Linuksie.

Szczególnie narażeni mogą być operatorzy chmur, którzy uruchamiają maszyny wirtualne wielu klientów na wspólnej infrastrukturze. Izolacja tych środowisk stanowi podstawę bezpieczeństwa takich usług. Ucieczka z jednej maszyny może zagrozić nie tylko jej właścicielowi, lecz także innym użytkownikom tego samego hosta.

Nie oznacza to jednak, że każdy serwer z Linuksem można automatycznie przejąć w ten sposób. Ryzyko zależy od podatnej wersji jądra i konfiguracji systemu. Nie ma też potwierdzonych informacji o wykorzystaniu PwnEscape w rzeczywistych atakach.

Poprawka już istnieje, ale administratorzy muszą działać

PwnEscape przypomina, że izolacja maszyn wirtualnych zależy również od bezpieczeństwa komponentów znajdujących się pod nimi. Nawet jeśli systemy gości są prawidłowo skonfigurowane, błąd w jądrze hosta może zagrozić całej infrastrukturze. Dla administratorów serwerów i operatorów chmur sprawdzenie aktualizacji powinno być teraz priorytetem.