v4bel/itscapeCVE-2026-46316 эксплойт для побега гость-хост KVM/arm64, использующий состояние гонки в эмуляции vGIC-ITS для выполнения кода ядра хоста из непривилегированного гостя.
Этот документ описывает уязвимость ITScape (CVE-2026-46316), о которой сообщил и исправил Hyunwoo Kim (@v4bel). Это уязвимость побега KVM, которая позволяет гостю сбежать на хост в среде KVM/arm64 и выполнять команды на хосте с привилегиями ядра (root). Насколько известно общественности, это первое исследование эксплойта побега гостя на хост, нацеленное на KVM/arm64.
ITScape использует состояние гонки в эмуляции vGIC-ITS (Interrupt Translation Service) в KVM/arm64. Он запускает ошибку только действиями на стороне гостя для побега на хост и может угрожать изоляции гостя-хоста на хостах KVM/arm64, которые принимают недоверенных гостей, особенно в многопользовательских arm64 публичных облаках.
В отличие от часто публикуемых побегов QEMU, ошибка находится во внутриядерном KVM, а не в пользовательском пространстве QEMU, поэтому она работает независимо от эмуляции QEMU и может выполнять команды на хосте с привилегией ядра хоста, а не с привилегией пользовательского процесса (такого как QEMU).
За подробной технической информацией обращайтесь сюда.
[!NOTE] После сообщения об этой уязвимости в [email protected] согласованный эмбарго истек, поэтому этот документ ITScape теперь опубликован. Временную шкалу раскрытия см. в документе с техническими подробностями.
Для безопасного тестирования рекомендуется запускать PoC под QEMU TCG. (Запуск уязвимости не имеет ничего общего с QEMU.) При запуске под QEMU TCG PoC имеет следующую структуру.
QEMU TCG: emulates an arm64 CPU (including EL2) so an arm64 kernel runs as the KVM host
└─ arm64 Host Kernel: the KVM host and the escape target
└─ poc: opens the HOST's /dev/kvm and creates one guest VM "G" (uid=1000)
└─ 1. G's guest code (run by poc via KVM_RUN) performs GIC/ITS MMIO
2. traps into the HOST's in-kernel KVM -> double-put -> HOST kernel code-exec
Этот PoC — не полностью оружизированный эксплойт, который сразу запускается в облачной среде arm64, а демонстрационный код, воспроизводящий уязвимость и полную цепочку эксплойта на основе kvm selftest. Ожидается, что атакующий, знакомый с реализацией стека виртуализации целевого облака, не найдет переход к оружизированию сложным, но он включает портирование прямой конструкции на стороне хоста из selftest на реальный путь, управляемый гостем, и настройку адресов, гаджета, смещений, тайминга гонки и так далее под версию и конфигурацию целевого ядра. Оружизированный реальный эксплойт существует, но не публикуется.
# ./build.sh <linux>/tools/testing/selftests/kvm
# ./qemu.sh <kernel-image> <initramfs>
# ./poc
...
[+] /ITScape created by the host kernel (owner uid=0). verify: ls -la /ITScape
# ls -la /ITScape
-rw-r--r-- 1 0 0 0 Jun 9 00:02 /ITScape
Этот PoC предназначен для предоставления точной информации. Не используйте его на системах, которые вы не уполномочены тестировать.
ITScape (CVE-2026-46316) охватывает диапазон от 8201d1028caa (2024-04-25) до 13031fb6b835 (2026-06-05).
Если вы управляете хостом arm64 KVM, который принимает многопользовательских гостей, или используете экземпляр на таком хосте, проверьте, что патч 13031fb6b835 применен к ядру хоста (операторы напрямую, арендаторы через своего провайдера). Кроме того, поскольку это новый класс уязвимостей, ожидается появление дополнительных вариантов и последующих уязвимостей, так что будьте внимательны. Тем не менее, вам нужно будет различать, действительно ли последующая уязвимость может быть запущена только действиями гостя без действий хоста, и действительно ли она эксплуатируема.
Нет. Уязвимость находится в arch/arm64/kvm/vgic/. Если вы не на хосте arm64 KVM, вам не нужно беспокоиться об этой уязвимости.
Да. Управление MMIO GIC/ITS требует привилегий гостевого ядра (EL1). Когда вам выделяют экземпляр в публичном облаке, у вас обычно есть root на вашей собственной ВМ, так что это выполняется. В сценарии без гостевого root его необходимо объединить с LPE, таким как Dirty Frag.