Трилогия побегов из KVM

ITScape (CVE‑2026‑46316)

Januscape (CVE‑2026‑53359)

Zapscape (CVE‑2026‑64561)

Zapscape: побег с гостевой системы на хост в KVM/x86

Аннотация

В этом документе описывается уязвимость Zapscape (CVE-2026-64561), которую обнаружил и о которой сообщил Hyunwoo Kim (@v4bel). Это уязвимость побега из KVM, которая позволяет гостевой системе выйти на хост в среде KVM/x86 и выполнять на хосте команды с привилегиями ядра (root).

Zapscape — это уязвимость использования после освобождения (use-after-free) в эмуляции теневой MMU KVM/x86, а именно в рекурсивном пути zap, который выполняется при освобождении теневых страниц. Её можно вызвать одними лишь действиями гостевой системы, чтобы повредить теневую страницу ядра хоста, и она может угрожать изоляции гость—хост для KVM/x86-хостов, принимающих недоверенные гостевые системы и предоставляющих вложенную виртуализацию, особенно мультитенантным публичным x86-облакам.

Подробную техническую информацию см. здесь.

[!NOTE] После сообщения об этой уязвимости в [email protected] согласованное эмбарго завершилось, поэтому эксплоит опубликован в oss-security, а также опубликован этот документ о Zapscape. Хронологию раскрытия см. в документе с техническими подробностями.

Структура PoC

PoC написан под AMD, и для безопасного тестирования его рекомендуется запускать под QEMU TCG. PoC имеет следующую структуру.

L0: Linux 7.1.3 + KVM_AMD on an x86_64 CPU (AMD SVM/NPT) emulated by QEMU TCG. The escape target
  └─ L1: the guest poc creates. Switching long -> PAE aliases one shadow page as both child and pinned root, and L1 then escalates the UAF into L0 kernel code-exec
       └─ L2: the guest L1 VMRUNs. Its memory touches trigger L0's quota reclaim -> recursive zap with no root_count guard -> UAF

Этот PoC — не боевой эксплоит, который сразу выполняется в облачном окружении, а демонстрационный код, воспроизводящий уязвимость и полную цепочку эксплоита поверх QEMU TCG. Чтобы использовать его в реальном облачном окружении, действия L1, выполняемые PoC, необходимо перенести в модуль ядра гостевой системы, а эксплоит — портировать под kconfig ядра хоста. Это несложная задача.

Использование PoC

1. Загрузите исходный код уязвимого ядра v7.1.3, затем соберите образ ядра на основе прилагаемого kconfig.
2. Соберите PoC, затем составьте подходящий initramfs с помощью BusyBox или аналогичных средств и поместите собранный PoC в initramfs.

# gcc -O2 -g -static -pthread poc.c -o poc

3. Загрузите целевую систему Linux 7.1.3 следующей командой. Тестируйте на QEMU v9.2.0 или новее.

# ./qemu.sh bzImage initramfs.cpio.gz

4. После загрузки QEMU TCG запустите PoC. При успешном эксплоите он выходит из гостевой системы и создаёт на хосте файл /Zapscape, принадлежащий root.

 /$$$$$$$$  /$$$$$$  /$$$$$$$
|_____ $$  /$$__  $$| $$__  $$
     /$$/ | $$  \ $$| $$  \ $$
    /$$/  | $$$$$$$$| $$$$$$$/
   /$$/   | $$__  $$| $$____/
  /$$/    | $$  | $$| $$
 /$$$$$$$$| $$  | $$| $$
|________/|__/  |__/|__/

[+] /Zapscape created by the target KVM host kernel (owner uid=0, mode=0644).
[+] exploit completed - verify with: ls -la /Zapscape
zapscape(uid=65534)$ ls -la /Zapscape
-rw-r--r--    1 root     root             0 Jul 29 05:27 /Zapscape
zapscape(uid=65534)$

Этот PoC предназначен для предоставления точной информации. Не используйте его в системах, для тестирования которых у вас нет разрешения.

Затронутые версии

Zapscape (CVE-2026-64561) охватывает диапазон от f95eec9bed76 (2020-07-08) до 2abd5287f083 (2026-07-21).

FAQ

Каково влияние этой уязвимости?

То же, что и у Januscape (CVE-2026-53359):

1. Побег из KVM: Только действиями на стороне гостевой системы злоумышленник может скомпрометировать хост, на котором работает его ВМ. Например, арендовав всего один инстанс в публичном облаке, злоумышленник может вызвать панику ядра хоста и остановить все остальные арендуемые ВМ на той же физической машине (DoS), либо выполнить код с root-привилегиями на хосте и захватить хост со всеми гостевыми системами на нём (RCE).
2. LPE: В таких дистрибутивах, как RHEL, /dev/kvm доступен для записи всем (0666), поэтому непривилегированный пользователь также может использовать эту уязвимость как LPE для получения root. При использовании в качестве LPE доступны ioctl VMM на стороне хоста, поэтому эксплоит становится проще и стабильнее.

Как это связано с Januscape?

Она возникает в той же теневой MMU, но это отдельная уязвимость с другой первопричиной.

Тем не менее, в отличие от Januscape, на Intel её можно вызвать только тогда, когда L1 доступны оба значения длины обхода страниц EPT — 4 и 5. Это важный момент при оценке затронутого диапазона, поэтому его нужно точно понимать. См. документ с техническими подробностями.

Возникает ли эта уязвимость в QEMU?

Нет. Как и Januscape, она возникает во внутриядерном KVM, поэтому срабатывает независимо от эмуляции QEMU. Из-за этого она может угрожать и крупным публичным облакам, которые реализуют и используют собственный стек виртуализации.

Нужен ли root внутри гостевой ВМ?

Да. Требуются привилегии ядра на уровне L1. Когда вам выделяется инстанс в публичном облаке, у вас обычно есть root в вашей собственной ВМ, так что это условие выполняется. В сценарии без root в гостевой системе её необходимо комбинировать с LPE, например с Dirty Frag.

Как вы думаете, уязвимости в KVM будут появляться и дальше?

Да. Я рекомендую выстроить устойчивый процесс установки исправлений для гипервизоров хостов. Зима близко.

Планируете ли вы продолжение после трилогии?

Надеюсь, что нет.