Krąży kolejna poważna podatność, tym razem najgorszy scenariusz dla chmury: ucieczka z maszyny wirtualnej na hosta. Nazwana Januscape i oznaczona jako CVE-2026-53359, siedzi w kodzie shadow MMU hypervisora KVM. Ma około 16 lat i według autorów jest pierwszym publicznie znanym exploitem guest-to-host działającym zarówno na Intelu, jak i na AMD. Odkrył ją Hyunwoo Kim (@v4bel).

Dla środowisk wielodostępnych to podatność klasy „gasi światło": jeden złośliwy najemca może wyjść ze swojej VM i dobrać się do hosta, a przez niego do wszystkich pozostałych gości na tej samej maszynie fizycznej.

Gdzie siedzi błąd

KVM na x86 do wirtualizacji pamięci używa albo sprzętowego wsparcia (Intel EPT, AMD NPT), albo starszego mechanizmu shadow paging. Shadow MMU utrzymuje własne strony księgujące, które odwzorowują tablice stron gościa. Ten kod jest w jądrze praktycznie niezmieniony od 2010 roku (jądro 2.6.36) i jest wspólny dla backendu Intela i AMD. Stąd jeden błąd trafia w obie platformy naraz.

Na czym polega

To use-after-free wynikające z pomylenia typów. KVM, szukając strony księgującej do ponownego użycia, dopasowywał kandydatów wyłącznie po numerze ramki gościa (GFN), nie sprawdzając, czy strona faktycznie pełni tę samą rolę: ten sam poziom tablicy stron i ten sam tryb dostępu. Dwie różne strony mogą mieć ten sam adres, a robić coś zupełnie innego.

Przy odpowiedniej sekwencji operacji gościa z użyciem zagnieżdżonej wirtualizacji dochodzi do wyścigu: host wiąże wpis shadow page z niewłaściwym GFN. Później nieaktualny wpis odwrotnego mapowania (rmap) zostaje wyłuskany podczas dirty logging albo unieważnienia przez MMU-notifier, co uszkadza pamięć jądra hosta. Co ważne, atakujący kontroluje, gdzie trafi zapis, ale nie co zostanie zapisane. To wystarcza, żeby zbudować z tego pełną kontrolę.

Dlaczego Intel i AMD

Błąd zachowuje się tak samo na obu architekturach, bo shadow MMU jest współdzielony. Różni się tylko ostatni, najtrudniejszy krok, czyli zamiana korupcji w pełne przejęcie, i to on wymaga innej pracy na Intelu, a innej na AMD.

Jest jeden warunek: nested virtualization musi być włączona na hoście. Nawet jeśli host domyślnie używa sprzętowego EPT lub NPT, włączona zagnieżdżona wirtualizacja wpycha KVM z powrotem w starą ścieżkę shadow MMU, czyli dokładnie tam, gdzie leży błąd.

Co potrafi exploit

Atakujący potrzebuje roota wewnątrz gościa, co na wynajętej instancji chmurowej jest normą. Mając to:

  • Publiczny PoC niezawodnie panikuje hosta z poziomu gościa. Sam w sobie to już atak na dostępność: wywracasz host i kładziesz wszystkie inne VM na tej maszynie.
  • Wstrzymana, pełna wersja według autora uruchamia kod jako root na hoście. To otwiera dostęp do wszystkich pozostałych gości współdzielących tę fizyczną maszynę.

Innymi słowy, upada gwarancja izolacji, na której stoi cała wirtualizacja wielodostępna.

Trzeba załatać dwa CVE

To ważne: pełne zamknięcie dziury wymaga dwóch sprzężonych poprawek, nie jednej.

  • CVE-2026-53359 to właściwy Januscape (commit 81ccda30b4e8)
  • CVE-2026-46113 to bliźniaczy use-after-free w tej samej logice ponownego użycia stron (commit 0cb2af2ea66a, maj 2026)

Załatanie tylko jednego zostawia system podatnym.

Jak się bronić

Zaktualizuj jądro. Poprawka trafiła do mainline 19 czerwca, a 4 lipca 2026 wyszły załatane wydania stabilne:

7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211, 5.10.260

Jeśli nie możesz od razu zaktualizować, odetnij ścieżkę ataku, wyłączając zagnieżdżoną wirtualizację dla niezaufanych gości:

# Intel
echo "options kvm_intel nested=0" > /etc/modprobe.d/kvm-nested.conf
# AMD
echo "options kvm_amd nested=0" > /etc/modprobe.d/kvm-nested.conf

Po przeładowaniu modułu (lub reboocie) sprawdź:

cat /sys/module/kvm_intel/parameters/nested   # Y albo N

Jeśli nie udostępniasz gościom nested virt, to i tak dobra praktyka trzymać to wyłączone. To spora powierzchnia ataku dla funkcji, której większość obciążeń nie potrzebuje.

Kalendarium

  • 28 maja 2026: poprawka bliźniaczego CVE-2026-46113 (commit 0cb2af2ea66a)
  • 19 czerwca: właściwy fix Januscape scalony do mainline (commit 81ccda30b4e8)
  • 4 lipca: załatane wydania stabilne dla wszystkich wspieranych linii

Wniosek

Januscape to przypomnienie, że najstarszy kod potrafi być najgroźniejszy. Ścieżka shadow MMU leżała nietknięta od 2010 roku, a mimo to dawała drogę z gościa prosto do jądra hosta na obu głównych architekturach. Jeśli prowadzisz host z niezaufanymi gośćmi, potraktuj to jak pożar: zaktualizuj jądro do wersji z 4 lipca lub później, a do czasu aktualizacji wyłącz nested virtualization.

Przy okazji warto zajrzeć do naszego opisu innej świeżej dziury w jądrze, DirtyClone, bo to kolejny przykład, jak lokalna eskalacja obala założenia o izolacji.

Źródła: Cloud Security Alliance Labs, The Hacker News, SecurityWeek