ITScape: Як вразливість у KVM/arm64 дозволяє захопити хост-сервер

Уразливість типу «використання після звільнення» (use-after-free) у підсистемі KVM/arm64 ядра Linux дає змогу спеціально підготовленій віртуальній машині вирватися зі своєї «пісочниці» та отримати повний контроль над хост-системою. Ця проблема, що отримала ідентифікатор CVE-2026-46316 та назву ITScape, є першим публічно задокументованим успішним експлойтом для втечі з гостьової системи на хост для KVM на архітектурі arm64. Це змушує всіх хмарних провайдерів, що використовують багатокористувацькі ARM-сервери, перейти в режим екстреного оновлення .

Про вразливість повідомив дослідник Хьонву Кім (Hyunwoo Kim) на початку червня 2026 року. Проблема не є суто теоретичною — на GitHub опубліковано повністю робочий код для демонстрації експлойту (Proof-of-Concept). Він ініціює «стан гонитви» за допомогою одночасної роботи декількох потоків віртуального процесора, які надсилають команди DISCARD ITS, поки кеш трансляції LPI проходить процедуру інвалідації . Результат — повна компрометація хосту зсередини ненадійної віртуальної машини.

Що таке ITScape?

ITScape — це «стан гонитви» (race condition) у реалізації сервісу трансляції переривань віртуального контролера переривань (vGIC-ITS), що вбудований в ядро KVM. Цей сервіс обробляє трансляцію логічних переривань процесора (LPI) для віртуалізованих гостьових систем на arm64. Коли запис у кеші трансляції потребує інвалідації, ядро проходить по всіх записах та звільняє посилання на них. Вразливість полягає в тому, що функція інвалідації зменшувала лічильник посилань на кожен запис, який повертав ітератор — включаючи ті записи, які паралельна операція вже видалила з кешу .

Це подвійне зменшення лічильника посилань створює класичну ситуацію «використання після звільнення» (use-after-free, UAF): два шляхи виконання коду можуть почати працювати з пам'яттю, яка вже була звільнена, що дає зловмиснику вікно для маніпуляцій із «купою» та, в кінцевому рахунку, для перехоплення контролю над виконанням коду на рівні ядра хосту .

Помилка знаходиться у функції vgic_its_invalidate_cache(), яка проходить по кешу трансляції за допомогою xa_for_each() і викликає vgic_put_irq() для ітерованого вказівника, а не для значення, безпечно повернутого функцією xa_erase(). Оскільки викликати цю функцію можуть різні контексти з різними блокуваннями, «стан гонитви» цілком досяжний з гостьової системи шляхом одночасного надсилання команд ITS, запису в GITS_CTLR та очищення EnableLPIs у редистриб'юторі .

Чому це важливо: перша в історії втеча з віртуальної машини KVM на ARM

Хоча втечі з гостьових систем на хост трапляються рідко, це найнебезпечніший клас вразливостей гіпервізора, оскільки вони руйнують бар'єр ізоляції, на якому базуються хмарні обчислення. Попередні публічні втечі з KVM були націлені на архітектуру x86, зазвичай через QEMU або код, специфічний для процесорів AMD . ITScape — це перший робочий експлойт, який демонструє втечу з непривілейованої гостьової системи на arm64 через код гіпервізора, вбудований безпосередньо в ядро — без використання помилок у емуляторах простору користувача .

Для хмарних провайдерів, які використовують сервери на базі AWS Graviton, Ampere Altra або інші ARM-хости з KVM для багатокористувацьких навантажень, гостьова система може:

• Читати та записувати довільні дані в пам'ять ядра хосту.
• Отримати виконання коду на нульовому кільці захисту (ring 0) хосту.
• Переміщуватися латерально (lateral movement) до інших віртуальних машин, контейнерів або мережі хосту.

Більшість команд безпеки оцінили цю вразливість вище 9.0 балів за шкалою CVSS, що відображає її критичну серйозність .

Першопричина в деталях

Вразливий код знаходиться в шляху інвалідації кешу трансляції LPI. Коли ядру потрібно очистити записи кешу, воно ітерується по структурі XArray за допомогою xa_for_each() і викликає vgic_put_irq() для зменшення лічильника посилань на кожен запис. Проблема в тому, що xa_for_each() може повертати записи, які вже були видалені конкурентною операцією — наприклад, командою DISCARD ITS з іншого віртуального процесора. Цикл інвалідації все одно зменшує лічильник посилань для цього вже видаленого запису, спричиняючи подвійне звільнення та, як наслідок, ситуацію «використання після звільнення» .

Попередня вразливість у тому ж коді, CVE-2024-26598, була частково виправлена і вирішувала UAF у шляху влучання в кеш трансляції LPI шляхом підвищення лічильника посилань у vgic_its_check_cache() перед зняттям блокування. Однак те виправлення не охопило шлях інвалідації, залишивши «стан гонитви» можливим для експлуатації через іншу послідовність тригерів .

Виправлення

Офіційне виправлення змінює vgic_its_invalidate_cache() таким чином, що vgic_put_irq() викликається лише для значення, яке повернула функція xa_erase(), а не для кожного запису, який зачіпає ітератор. Повідомлення про внесення змін говорить: "KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry" .

Оскільки xa_erase() атомарно видаляє та повертає старий запис — або повертає NULL, якщо запис уже було видалено — виправлення гарантує, що лічильник посилань буде зменшено рівно один раз, усуваючи вікно подвійного звільнення. Патч було внесено до основної гілки ядра на початку червня 2026 року, і він був швидко перенесений до стабільної серії 6.x приблизно 8–10 червня 2026 року . Основні дистрибутиви, включаючи Red Hat, SUSE та Debian, випустили бекпортовані виправлення для своїх підтримуваних гілок ядра .

Вразливі версії

• Коли з'явилась: Кінець квітня 2024 року, коли кеш трансляції LPI було вперше додано до KVM/arm64 .
• Вразливий період: Основна гілка ядра, зібрана приблизно з квітня 2024 року до початку червня 2026 року .
• Виправлено: Основний патч внесено на початку червня 2026 року; включено в останні стабільні ядра 6.x та бекпорти дистрибутивів .

Експлойт для демонстрації (Proof-of-Concept)

Хьонву Кім опублікував робочий експлойт на GitHub приблизно 9–10 червня 2026 року. Репозиторій містить повний вихідний код, покрокові інструкції з відтворення та технічний опис техніки експлуатації вразливості . Експлойт активує «стан гонитви», координуючи потоки віртуальних процесорів, які одночасно видають команди DISCARD та здійснюють пошук у кеші трансляції LPI, що дозволяє точно відтворити ситуацію «використання після звільнення» для виконання коду на хості.

Публічна доступність надійного PoC означає, що стандартні сканери вразливостей та реальні зловмисники можуть легко взяти її на озброєння, що значно скорочує вікно між розкриттям інформації та активними атаками.

Термінові заходи безпеки для операторів хмарної ARM-інфраструктури

Якщо ви керуєте багатокористувацькою інфраструктурою KVM на arm64 — будь то AWS Graviton, Ampere Altra чи будь-яка подібна платформа — це слід розглядати як надзвичайну ситуацію для негайного встановлення патчів.

1. Встановіть патч для ядра хост-системи негайно. Застосуйте останнє стабільне ядро, що містить виправлення від початку червня 2026 року, або бекпортований пакет від вашого дистрибутива .
2. Вимкніть вбудований в ядро vGIC-ITS для ненадійних гостьових систем, якщо не можете оновитися негайно. У QEMU це можна зробити, примусово перенаправивши емуляцію GICv3 ITS у простір користувача, або не відкриваючи можливості GICv3 ITS для ненадійних користувачів .
3. Не покладайтеся на посилення захисту всередині гостьової системи. Це помилка рівня гіпервізора, і жодних обхідних шляхів всередині віртуальної машини не існує .
4. Проведіть аудит свого парку серверів на наявність вразливих ядер. Будь-який хост KVM на arm64 з ядром, зібраним між квітнем 2024 та початком червня 2026 року, який використовує vGIC-ITS, перебуває в зоні ризику .
5. Відстежуйте індикатори експлуатації. Після публікації коду PoC, активне сканування та спроби компрометації є високоймовірними .