Zapscape CVE-2026-64561: zagnieżdżona VM mogła uciec do hosta KVM

Zapscape, śledzona jako CVE-2026-64561, jest podatnością use-after-free w shadow MMU KVM/x86. Uprzywilejowany kod działający w maszynie L1 z włączoną wirtualizacją zagnieżdżoną mógł doprowadzić do użycia zwolnionej struktury tablic stron przez kernel hosta. Badacze pokazali ścieżkę od działań wewnątrz gościa do wykonania kodu jako root na hoście.

To istotna granica dla chmur i laboratoriów, które świadomie przekazują tenantowi flagi VMX lub SVM. Root w wynajętej maszynie jest zwykłym uprawnieniem klienta, nie dowodem wcześniejszego przejęcia hypervisora. Bezpieczeństwo musi zakładać, że uprzywilejowany guest zachowuje się wrogo.

Co psuje się w shadow MMU

KVM utrzymuje struktury odwzorowujące widok pamięci gościa na pamięć fizyczną hosta. Przy nested virtualization L1 uruchamia własne maszyny L2, a host musi emulować dodatkową warstwę translacji. Shadow pages są usuwane — „zapowane” — gdy mapowania tracą ważność lub KVM odzyskuje limit stron MMU.

W wadliwej ścieżce rekurencyjne zapowanie mogło zwolnić root shadow page, która nadal była używana podczas obsługi błędu strony. Dalsze operacje pracowały na nieaktualnym wskaźniku. Taki use-after-free w kernelu hosta daje możliwość kontrolowanej korupcji pamięci i przełamania granicy guest–host.

Rekord CVE-2026-64561 oraz poprawki w drzewach stabilnych Linuksa określają dotknięte wersje. Warunkiem praktycznym jest dostęp do nested virtualization i uprzywilejowany kod w L1. Hosty, które nie przekazują tych funkcji nieufnym VM, mają znacznie mniejszą powierzchnię tego konkretnego scenariusza.

Gdzie szukać ekspozycji

Najpierw ustal nie tylko, czy moduł KVM ma nested=1, lecz czy funkcja jest przekazywana konkretnym klasom instancji. Sprawdź szablony libvirt, profile chmurowe, Kubernetes virtualization, platformy szkoleniowe, usługi build oraz środowiska uruchamiające emulatory Androida.

Nested virtualization bywa włączana tymczasowo do testów, a później pozostaje w obrazie lub polityce. Dlatego inwentaryzacja na poziomie hosta bez powiązania z konfiguracją gościa może dać fałszywe poczucie bezpieczeństwa.

Reakcja i hardening

1. Zainstaluj kernel zawierający poprawkę CVE-2026-64561 i uruchom host ponownie, aby nowy kod faktycznie działał.
2. Wyłącz nested virtualization dla tenantów, którzy jej nie potrzebują, oraz usuń flagi vmx/svm z ich wirtualnych CPU.
3. Migruj nieufne VM z niezałatanych hostów i nie uruchamiaj ich ponownie do czasu potwierdzenia wersji kernela.
4. Oddziel pule hostów oferujące nested virtualization od zwykłych workloadów i danych wysokiej wartości.
5. Monitoruj zmiany definicji VM, ekspozycję flag CPU, nietypowe restarty gości i błędy KVM/MMU w logach kernela.
6. Ogranicz dostęp do /dev/kvm w kontenerach i runnerach; samo istnienie urządzenia może tworzyć dodatkową warstwę gościa.
7. Po podejrzeniu ucieczki traktuj cały host i współdzielone sekrety jako potencjalnie naruszone, nie tylko jedną VM.

Jak potwierdzić stan floty KVM

CMDB powinna przechowywać trzy osobne informacje: wersję pakietu kernela, wersję rzeczywiście uruchomioną oraz ekspozycję nested virtualization dla konkretnej VM. Dopiero ich połączenie daje odpowiedź, czy workload mógł wywołać podatną ścieżkę. Przy live migration trzeba sprawdzać zarówno host źródłowy, jak i docelowy, bo niezaktualizowany węzeł może ponownie wprowadzić ryzyko po poprawnym restarcie innej części klastra.

W logach należy zachować komunikaty KVM, Oops i trace’y MMU poza hostem. Nagły crash qemu, błąd shadow-page accounting albo nietypowa sekwencja tworzenia L2 może być wskazówką, ale nie jest samodzielnym dowodem eksploatacji. Dla puli wysokiego ryzyka sensowne jest wymuszenie measured boot i atestacji wersji kernela przed przyjęciem nieufnej VM. Dzięki temu scheduler nie opiera decyzji na deklaracji obrazu, lecz na stanie uruchomionego hosta.

Fakty i analiza

Źródła potwierdzają use-after-free, wymaganie zagnieżdżonej wirtualizacji i poprawkę kernela. Publiczna demonstracja pokazuje możliwość wpływu, ale nie oznacza aktywnego wykorzystania na wszystkich hostach KVM. Rekomendacja osobnych pul jest wnioskiem architektonicznym Breachroad.

Audyt bezpieczeństwa chmury może połączyć wersje hostów z faktycznymi flagami VM. Szkolenia techniczne pomagają zespołom platformowym ćwiczyć reakcję na podatność przekraczającą granicę wirtualizacji.