ITScape: первый в истории взлом из гостевой VM в KVM/arm64

Июнь 2026 года ознаменовался событием, которого давно опасались инженеры облачной безопасности. Исследователь Хёну Ким (Hyunwoo Kim) раскрыл детали и опубликовал рабочий proof-of-concept эксплойта уязвимости, получившей название ITScape (CVE-2026-46316). Это первый в истории задокументированный случай успешного «побега» из гостевой виртуальной машины напрямую на хостовую систему в среде KVM/arm64 .

Уязвимость позволяет атакующему, имеющему доступ лишь к обычной виртуальной машине на уязвимом ARM-сервере, полностью скомпрометировать хост, получить права уровня Ring 0 в его ядре, читать и изменять произвольные участки памяти, а также атаковать другие VM и контейнеры, работающие на том же физическом оборудовании. Большинство команд безопасности присвоили ей рейтинг выше 9.0 по шкале CVSS, то есть «критический» .

В чем суть уязвимости ITScape?

Технически ITScape — это состояние гонки в подсистеме KVM, отвечающей за эмуляцию виртуального контроллера прерываний GIC и его сервиса трансляции (ITS). Если упростить: когда одна часть кода пытается очистить кэш трансляции, а другая одновременно обращается к нему, возникает ситуация «использование после освобождения» (use-after-free, UAF).

Проблема кроется в функции vgic_its_invalidate_cache(). Она проходила по кэшу трансляции с помощью xa_for_each() и высвобождала ресурсы для каждой записи, возвращенной итератором. Но другая, конкурентная операция (например, обработка команды DISCARD из VM) могла уже удалить эту запись. В итоге счетчик ссылок уменьшался повторно для уже освобожденного объекта — классический double-put .

Интересно, что похожая уязвимость в том же коде (CVE-2024-26598) исправлялась ранее, но тот патч закрыл лишь часть проблемы в пути попадания в кэш (vgic_its_check_cache()), оставив без внимания путь инвалидации .

Чем ITScape отличается от предыдущих побегов из VM?

До сих пор публичные взломы KVM с побегом из гостевой системы, как правило, либо затрагивали x86-архитектуру, либо эксплуатировали ошибки в пользовательском эмуляторе QEMU, а не в коде ядра .

ITScape — первый рабочий эксплойт, который:

1. Нацелен именно на ARM64;
2. Эксплуатирует уязвимость непосредственно внутриядерного KVM, без ошибок в userspace-компонентах .

Для ARM-облаков, которые активно развиваются (например, процессоры AWS Graviton, Ampere Altra), это означает, что стандартные песочницы виртуализации больше не являются надежной границей безопасности без установленного патча.

Патч и затронутые версии

Исправление, переданное в upstream-ядро Linux, меняет логику vgic_its_invalidate_cache() так, что vgic_put_irq() вызывается только для значения, возвращенного атомарной функцией xa_erase(), а не для каждой итерации цикла. Если запись уже была удалена конкурентным потоком, xa_erase() вернет NULL, и лишнего высвобождения не произойдет .

• Период уязвимости: Ядра Linux, собранные примерно с конца апреля 2024 по начало июня 2026 года.
• Исправлены: Свежие сборки стабильной серии 6.x (от 8-10 июня 2026), а также бэкпорты от Red Hat, SUSE, Debian и других крупных дистрибутивов .

Публичный эксплойт уже на GitHub

Хёну Ким опубликовал полный исходный код эксплойта на GitHub около 9-10 июня 2026 года. Репозиторий включает:

• Набор потоков vCPU, одновременно вызывающих DISCARD и операции чтения кэша трансляции;
• Инструкции по воспроизведению для уязвимых версий ядра;
• Техническое описание техники эксплуатации .

Доступность надежного PoC означает, что время на установку патчей резко сократилось: сканеры уязвимостей и реальные атакующие могут практически мгновенно взять код на вооружение.

Что делать прямо сейчас операторам ARM64-облаков

Если вы управляете мультитенантной инфраструктурой на ARM64 (AWS Graviton, Ampere, «Эльбрус» со сборками KVM и т.п.):

1. Немедленно обновите хостовое ядро. Примените патч из последней стабильной ветки, выпущенный в начале июня 2026, или бэкпортированный пакет от вашего дистрибутива .
2. Если патч невозможен здесь и сейчас, отключите использование внутриядерного vGIC-ITS для недоверенных гостей (например, в QEMU принудительно переключите эмуляцию GICv3 ITS на userspace) .
3. Не надейтесь на защиту изнутри VM. Это баг гипервизора: никакие настройки внутри гостевой ОС не предотвратят атаку .
4. Проведите аудит своего парка серверов. Если хост под ARM64 KVM использует ядро, собранное между апрелем 2024 и июнем 2026, и при этом эксплуатирует vGIC-ITS — система уязвима .
5. Мониторьте попытки вторжений. Открытый PoC делает высоковероятными сканирования и компрометацию в ближайшее время .