PwnEscape dotyczy sieciowej ścieżki jądra Linuksa, nie KVM

PwnEscape, czyli CVE-2026-99999, to luka w obsłudze ruchu IPv4 w jądrze Linuksa. Ścieżka prowadząca do błędu może zaczynać się w maszynie wirtualnej, ale podatny kod znajduje się po stronie hosta, a nie w KVM. To ważne rozróżnienie: aktualizacja samego systemu gościa nie naprawia jądra hosta.

Gdzie znajduje się PwnEscape

KVM udostępnia maszynom wirtualnym zasoby sprzętowe, a virtio-net i TAP mogą przekazywać ruch sieciowy między gościem a hostem. PwnEscape dotyczy dalszego etapu: przetwarzania sum kontrolnych pakietów IPv4 przez jądro Linuksa. Błędne metadane sumy kontrolnej pochodzące z mniej zaufanej ścieżki mogą doprowadzić do zapisu w nagłówku, który jądro wcześniej już przetworzyło. Luka leży więc w sieciowej ścieżce jądra hosta, nie w kodzie samego KVM. Poprawka w jądrze Linuksa dotyczy właśnie kontroli przetwarzania sum kontrolnych IPv4.

Jak metadane prowadzą do ujawnienia pamięci

Paulos Yibelo z pwn.ai opisał w swoim raporcie technicznym o PwnEscape przypadek, w którym odroczone uzupełnienie sumy kontrolnej zmieniło interpretowaną długość nagłówka IPv4 z 20 do 60 bajtów. Późniejsze dzielenie pakietu na fragmenty zaufało tej zmienionej wartości.

W opisanej geometrii pakietu jego logiczne dane liniowe obejmowały 28 bajtów: 20 bajtów nagłówka IPv4 i 8 bajtów ładunku. Gdy kolejny etap potraktował nagłówek jako 60-bajtowy, fragmentacja skopiowała 32 bajty spoza tej logicznej części danych. Yibelo opisał powtarzalne ujawnienie 32 bajtów pamięci hosta w swoim przypadku badawczym. To konkretny wynik tej demonstracji, nie miara dla każdego hosta ani każdego pakietu.

Co wykazały badania

Wyniki należy rozdzielić według środowiska. Yibelo opisał ujawnienie 32 bajtów, a osobno wybrane 64-bajtowe zapisy do jądra hosta oraz uruchomienie pomocniczego procesu z uprawnieniami roota. Ten drugi łańcuch zadziałał podczas czterech zimnych uruchomień w należącym do badacza środowisku KVM. Nie był to wynik uzyskania roota na produkcyjnym hoście dostawcy.

Co zmienia poprawka upstream

Zaakceptowana poprawka dodaje kontrolę początku sumy kontrolnej IPv4 i sprawdza go przed jej uzupełnieniem w pięciu miejscach używających tej operacji. Odrzuca przypadek, w którym początek sumy wypada przed końcem nagłówka IPv4. Yibelo opisuje tę zmianę jako dodatkową warstwę ochrony, a nie przebudowę całego sprawdzania pakietów przy wejściu do stosu sieciowego.

Dla administratora kluczowe jest miejsce aktualizacji: hostowy system operacyjny. Aktualizacja jądra wewnątrz maszyny wirtualnej nie zastępuje poprawki hosta. Wersje pakietów zależą od dystrybucji, dlatego trzeba stosować poprawkę przeznaczoną dla konkretnego systemu, a nie przenosić numeru wersji upstream na pakiet dostawcy.

Zakres AWS: usługi zarządzane a własne hosty

W biuletynie z 15 października 2026 r. AWS podało, że jego zarządzane usługi EC2, Lambda i Fargate nie są objęte podatnością. Osobno wskazało hosty KVM/virtio-net zarządzane przez klientów, jeśli działają na podatnym, niezałatanym jądrze. To rozróżnienie dotyczy zakresu określonego przez AWS, nie wszystkich usług chmurowych. Biuletyn bezpieczeństwa AWS zaleca takim klientom instalację właściwej aktualizacji hosta i ponowne uruchomienie go.

Dlaczego podawane są dwie oceny CVSS

CVE-2026-99999 ma dwie oceny CVSS 3.1, ponieważ Red Hat publikuje wynik dla własnych produktów, a obok niego wynik przypisany przez cve.org. Różnią się też założeniem dotyczącym wymaganych uprawnień: PR:N oznacza brak wymaganych uprawnień w wektorze, a PR:L niski poziom uprawnień.

Red Hat podaje oba wyniki i różnicę w metryce uprawnień w swojej poradzie dotyczącej CVE-2026-99999.