В ядре Linux исправили Januscape — уязвимость в гипервизоре KVM, которая позволяет атакующему выйти из гостевой виртуальной машины и выполнить код на физическом хосте. Ошибка получила идентификатор CVE-2026-53359 и затрагивает x86-системы с процессорами Intel и AMD.
Исследователь Хенву Ким продемонстрировал полноценный выход из виртуальной машины в программе Google kvmCTF. Публичная версия кода ограничена аварийной остановкой ядра хоста, но автор подтвердил существование закрытого эксплоита, который получает права root на физическом сервере.
Уязвимость находилась в коде KVM около 16 лет. Её появление связывают с веткой Linux 2.6.39 и реализацией теневой подсистемы управления памятью, которая используется при вложенной виртуализации. Проблема оставалась незамеченной с 2010 года и пережила множество поколений серверных процессоров и ядер Linux.
Исправление включили в основную ветку ядра 19 июня. Обновлённые стабильные выпуски вышли 4 июля: 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211 и 5.10.260.
KVM, или Kernel-based Virtual Machine, превращает Linux в гипервизор. Каждый клиент получает собственную виртуальную машину, которая должна быть изолирована от операционной системы хоста и соседних арендаторов.
Januscape ломает эту границу. Атакующий, уже контролирующий гостевую систему, может воздействовать на структуры памяти ядра хоста. Публичный демонстрационный модуль вызывает критическую ошибку и останавливает физический сервер. Закрытая версия эксплоита использует тот же дефект для выполнения кода с максимальными привилегиями.
После получения root-доступа к хосту нарушитель потенциально способен читать память других виртуальных машин, извлекать дисковые образы, менять настройки гипервизора и захватывать соседние среды. Такой результат особенно опасен для хостингов и облачных платформ, где на одном сервере работают системы разных клиентов.
Этот сценарий не означает, что один запуск публичного кода автоматически раскрывает все соседние машины. Опубликованный прототип вызывает отказ в обслуживании. Полноценный выход существует, но исследователь не раскрывает его из-за риска практического применения.
Многие известные способы выхода из виртуальных машин использовали ошибки в эмуляции устройств: сетевых карт, контроллеров дисков, графики или USB. Такая логика часто работает в QEMU — пользовательском процессе, который создаёт виртуальное оборудование.
Januscape устроена иначе. Ошибка находится непосредственно в коде KVM внутри ядра Linux. Все опасные операции обрабатываются модулем KVM и не передаются QEMU. Замена версии QEMU или отключение отдельных эмулируемых устройств поэтому не закрывают CVE-2026-53359.
Эта особенность делает Januscape заметным событием для отрасли. Уязвимость находится в одной из главных границ безопасности современной облачной инфраструктуры — механизме, который отвечает за разделение памяти гостевой машины и хоста.
KVM использует разные аппаратные технологии виртуализации. У Intel это VMX и таблицы EPT, у AMD — SVM и NPT. Ошибки в архитектурно-зависимом коде обычно работают только на процессорах одного производителя.
Januscape находится в общей для обеих архитектур подсистеме Shadow MMU — теневом блоке управления памятью KVM/x86. Исследователю потребовалось заменить лишь архитектурно-зависимые флаги таблиц страниц. Основная последовательность эксплуатации осталась одинаковой.
Автор называет Januscape первым публично известным исследованием полноценного выхода из гостевой KVM-машины, которое можно запустить и на Intel, и на AMD.
Обычная виртуальная машина работает как первый гостевой уровень, который принято обозначать L1. Вложенная виртуализация разрешает L1 самой стать гипервизором и запустить ещё одну машину — L2.
Такой режим нужен для тестовых лабораторий, облачных сред разработки, тренажёров безопасности и запуска гипервизоров внутри облака. Пользователь может поднять KVM, Hyper-V или другой совместимый слой виртуализации внутри арендованного сервера.
Современный KVM обычно полагается на аппаратные таблицы EPT или NPT. При запуске вложенной машины процессор не может напрямую обработать все уровни преобразования адресов. Физический хост начинает программно создавать теневую копию таблиц, которыми управляет гостевая система. Именно здесь включается уязвимый код Shadow MMU.
Для известного сценария эксплуатации атакующему нужен контроль над гостевой системой и доступная вложенная виртуализация. Публичный прототип загружает модуль ядра внутри гостя, формирует собственные структуры VMX или SVM и запускает вложенную машину. В облачной виртуальной машине права root обычно позволяют выполнить эти действия, если провайдер открыл соответствующие возможности процессора.
KVM создаёт теневые страницы, которые описывают отображение гостевой памяти в физическую память сервера. Каждая такая структура содержит номер гостевой страницы и роль — набор параметров, определяющих её назначение.
До исправления функция kvm_mmu_get_child_sp() проверяла номер страницы, но не сравнивала её роль. Если номер совпадал, KVM мог повторно использовать уже существующую структуру.
Januscape заставляет один и тот же номер страницы сначала описывать крупную область размером 2 Мбайт, а затем таблицу обычных страниц по 4 Кбайт. Номер остаётся прежним, но назначение структуры меняется.
KVM видит совпадение номера и ошибочно повторно использует теневую страницу с неподходящей ролью. После этого внутренний обратный указатель записывается под одним ключом, а удаляется уже по другому. Часть ссылки остаётся в служебной таблице после освобождения памяти.
Поздняя операция, например изменение области памяти или обработка уведомления подсистемы управления памятью, обращается к устаревшему указателю. Ядро получает доступ к уже освобождённой странице.
Этот класс ошибок называется use-after-free — «использование после освобождения». Освобождённую область может занять другой объект ядра. Атакующий старается подобрать такой объект и расположение данных, чтобы последующая запись изменила важное поле и перенаправила выполнение кода.
Januscape не выдаёт атакующему универсальную возможность записывать произвольные данные в любое место памяти. После освобождения KVM выполняет одну фиксированную запись и позволяет управлять главным образом её смещением.
Исследователю пришлось подобрать объект ядра, в котором такое значение попадёт в полезное поле. Подход различается между Intel и AMD из-за особенностей размещения объектов и поведения архитектурных компонентов. Автор отмечает, что вариант для AMD оказался немного проще.
Публичный прототип намеренно доводит повреждение до проверки целостности KVM. Ядро замечает несоответствие в обратных ссылках и вызывает аварийную остановку. Этот вариант подтверждает дефект и возможность атаки со стороны гостя, не раскрывая цепочку получения root.
Прототип размещён в открытом репозитории вместе с подробным техническим разбором. Он работает как модуль ядра внутри гостевой машины и поддерживает отдельные режимы для Intel и AMD.
Атакующему требуется выгрузить стандартный гостевой модуль KVM и загрузить исследовательский модуль. После этого код создаёт собственную вложенную среду, переключает запись таблицы страниц между крупным отображением и указателем на таблицу, а затем вызывает нужную последовательность ошибок страниц.
Результатом становится паника ядра физического сервера. Все виртуальные машины на таком хосте могут одновременно остановиться до перезагрузки или автоматического переноса нагрузки.
CISA отмечает наличие публичного прототипа и оценивает потенциальное техническое воздействие как полное. Массовую автоматическую эксплуатацию ведомство считает затруднённой. NVD пока не присвоила уязвимости собственную оценку CVSS.
Google запустила kvmCTF для поиска ранее неизвестных уязвимостей в KVM. Участник получает доступ к гостевой машине на выделенном физическом сервере и должен доказать воздействие на хост.
Программа устанавливает награду в $20 000 за отказ в обслуживании, $100 000 за произвольную запись в память и $250 000 за полный выход из виртуальной машины.
Хенву Ким использовал Januscape как уязвимость нулевого дня и продемонстрировал Google полноценное выполнение кода на хосте. Ars Technica сообщила о выплате исследователю максимальной награды в $250 000.
Google получает технические детали после появления исправления в основной ветке Linux. Такой порядок позволяет разработчикам ядра подготовить патч до передачи полного отчёта организаторам программы и публичного раскрытия.
Патч изменяет условие повторного использования теневой страницы. Теперь KVM сравнивает номер гостевой страницы и значение role.word, которое описывает назначение и параметры структуры.
Совпадения одного номера больше недостаточно. Если роли различаются, KVM создаёт подходящую страницу вместо повторного использования старой. Это сохраняет согласованность обратных указателей и не позволяет оставить ссылку на освобождённую память.
Основное исправление с идентификатором 81ccda30b4e8 вошло в главную ветку Linux 19 июня. Команда ядра затем перенесла его в поддерживаемые стабильные серии. Публичное раскрытие состоялось 6 июля после пятидневного периода координации с разработчиками дистрибутивов.
Небольшой размер патча не отражает серьёзность ошибки. Одна отсутствующая проверка роли позволяла гостю нарушить целостность структур памяти физического хоста.
Исправление присутствует в Linux 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211 и 5.10.260. Новые выпуски этих веток также должны содержать патч.
Сравнивать только номер ядра недостаточно. Разработчики Ubuntu, Debian, Red Hat, SUSE, Astra Linux и других дистрибутивов могут перенести исправление в более раннюю версию, сохранив прежний номер основной ветки.
Администратору следует проверять бюллетень производителя и наличие исправляющего изменения в конкретном пакете. Самостоятельно собранные и неподдерживаемые ядра старше 5.10 требуют ручного переноса патча либо перехода на актуальную ветку.
Установка нового пакета ядра тоже не завершает обновление. Хост нужно перезагрузить или применить подтверждённое поставщиком оперативное исправление. Работающая система продолжает использовать старое ядро, пока новое не загружено.
Canonical рекомендует до установки исправления отключить вложенную виртуализацию. Для Intel и AMD это можно сделать через параметры модулей:
options kvm_intel nested=0
options kvm_amd nested=0
Текущее состояние проверяется так:
grep . /sys/module/kvm_{amd,intel}/parameters/nested
Значение Y или 1 означает, что вложенная виртуализация включена. Значение N или 0 соответствует временной защите от известного сценария Januscape. После изменения параметров потребуется остановить виртуальные машины, перезагрузить модули KVM или перезапустить хост.
Отключение функции может сломать среды, где клиенты запускают собственные гипервизоры, эмуляторы Android, лаборатории безопасности или виртуальные кластеры. Оператору нужно проверить зависимости до массового изменения конфигурации.
Основная группа риска — многопользовательские хостинги с недоверенными гостями и включённой вложенной виртуализацией. Уязвимость также актуальна для корпоративных платформ, университетских облаков, систем разработки и серверов, где пользователи могут самостоятельно создавать виртуальные машины.
Canonical отдельно предупреждает о локальном сценарии. Пользователь или процесс с правом записи в /dev/kvm способен создать виртуальную машину и попытаться атаковать тот же хост. Поэтому сервер без запущенных ВМ нельзя автоматически считать безопасным.
Непривилегированные контейнеры обычно не имеют доступа к KVM. Привилегированный контейнер с проброшенным /dev/kvm может получить необходимые возможности и должен рассматриваться как полноценный источник риска.
Администраторам стоит проверить членство в группе kvm, права на /dev/kvm, конфигурации libvirt, Incus, LXD, Multipass и другие сервисы, которые позволяют пользователям создавать аппаратно ускоренные виртуальные машины.
Влияние Januscape зависит от архитектуры конкретного провайдера. Наличие KVM ещё не означает практическую уязвимость: нужен уязвимый пакет ядра и доступ к вложенной виртуализации.
Yandex Cloud сообщила, что её сервисы не затронуты. Платформа отключила вложенную виртуализацию и применила исправленные стабильные ядра.
