Исследователь по имени Хёнву Ким, известный в Twitter/X под ником @v4bel, нашёл уязвимость в гипервизоре KVM, которую сам назвал Januscape. Ей присвоен номер CVE-2026-53359. Речь идёт об ошибке типа use-after-free в коде теневого MMU — той части ядра Linux, которая отвечает за отображение памяти виртуальных машин на реальную память хоста. Проблема живёт в коде примерно 16 лет и работает одинаково что на Intel, что на AMD. По словам Кима, это первый публично известный случай, когда побег из гостевой машины на хост-систему воспроизводится сразу на обеих архитектурах x86.
Баг Ким отправил как zero-day в программу Google kvmCTF — контролируемую программу вознаграждений за поиск уязвимостей в KVM, где за полноценный побег из гостя на хост платят до 250 000 долларов. Опубликованный proof-of-concept вызывает панику ядра хоста — попросту говоря, крашит всю систему целиком со всеми виртуальными машинами на ней. Отдельный эксплойт, дающий полное выполнение кода на хосте, Ким пока не раскрывает.
Суть ошибки в том, как KVM управляет теневыми таблицами страниц — своей внутренней копией страничной таблицы гостя. Когда система решает переиспользовать страницу для отслеживания памяти, она сверяет только адрес этой страницы, но не её тип. А два разных типа страниц вполне могут делить один и тот же адрес, выполняя при этом совершенно разные функции. В результате внутренние записи KVM о том, кому какая память принадлежит, начинают путаться.
Из этой путаницы вытекают два сценария. Чаще всего ядро само обнаруживает повреждение данных и падает в панику — это защитный механизм, но он всё равно кладёт хост целиком вместе со всеми чужими виртуалками на нём. Реже происходит худший вариант: освобождённая страница переиспользуется до завершения очистки памяти, и процесс очистки пишет в память, которая ему уже не принадлежит. Атакующий контролирует, куда именно попадёт запись, хотя не полностью контролирует, что именно будет записано. Этого достаточно, чтобы довести атаку до произвольного выполнения кода на хосте. Само поведение бага одинаково на Intel и AMD, различается только финальный шаг эксплуатации — из-за архитектурных отличий процессоров.
Для атаки нужны две вещи: root внутри гостевой виртуальной машины (что нередкая ситуация на арендованных облачных инстансах) и включённая на хосте вложенная виртуализация. Здесь есть тонкость — даже хосты, которые по умолчанию используют аппаратные механизмы EPT или NPT, откатываются на устаревший программный shadow MMU, как только запускается nested virtualization. Именно в этом legacy-коде и сидит уязвимость. Участие QEMU или другого userspace-гипервизора не требуется — баг чисто внутри самого ядра KVM.
Ошибка была внесена коммитом 2032a93d66fa в августе 2010 года, во времена ядра линейки 2.6.36. Исправление — коммит 81ccda30b4e8 — попало в основную ветку 19 июня 2026 года. На практике под угрозой оказываются любые x86-системы, где размещаются недоверенные гостевые машины с включённой вложенной виртуализацией. Достаточно одной арендованной вредоносной виртуалки, чтобы уронить хост и все соседние машины на нём. А непубличный эксплойт Кима, если он реален, способен дать атакующему root на хосте — со всеми вытекающими последствиями для остальных гостей. Отдельная деталь касается RHEL и похожих дистрибутивов: там, где /dev/kvm открыт на запись для всех (режим 0666), тот же баг превращается в локальную эскалацию привилегий до root, хотя побег из гостя на хост считается более серьёзной проблемой.
Januscape — уже третье раскрытие уязвимостей ядра Linux от Кима примерно за два месяца. В мае 2026 года он опубликовал Dirty Frag (CVE-2026-43284 и CVE-2026-43500) — цепочку уязвимостей в работе с page cache, дающую детерминированный root-доступ на большинстве крупных дистрибутивов и продолжающую линию багов, начатую Dirty Pipe и Copy Fail. В июне того же года последовал ITScape (CVE-2026-46316) — первый публично продемонстрированный побег из гостя на хост на KVM/arm64, эксплуатирующий гонку в виртуальном контроллере прерываний. Januscape завершает эту серию как узкоспециализированная для x86 находка — proof-of-concept содержит отдельные пути кода для Intel и для AMD.
Стоит вспомнить, что программа kvmCTF от Google запущена в 2024 году именно потому, что KVM лежит в основе и Android, и Google Cloud. А в мае 2026 года уже фиксировалась похожая по природе, но технически иная проблема — CVE-2026-46113, тоже use-after-free в теневой страничной адресации x86 KVM, связанная с несовпадением rmap-записей. Получается, что за два месяца в одном и том же устаревшем участке кода нашли уже два разных use-after-free бага теневого MMU.
Исправление оказалось на удивление коротким — одна строка в функции kvm_mmu_get_child_sp(). Условие переиспользования страницы теперь проверяет не только номер гостевого фрейма (gfn), но и поле role.word, отвечающее за тип страницы. Страница переиспользуется, только если совпадают оба параметра. Автор патча — сопровождающий KVM Паоло Бонзини. Исправленные версии ядра вышли 4 июля 2026 года: 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211 и 5.10.260. Оценка по шкале CVSS от NVD пока не присвоена, но в рекомендациях прямо говорится — не ждать этой оценки, чтобы начать действовать.
Администраторам стоит проверить, включён ли в их x86-хостах коммит 81ccda30b4e8, причём смотреть лучше в changelog пакета, а не полагаться только на вывод uname -r — дистрибутивы нередко делают бэкпорты с собственной нумерацией версий. Если немедленно поставить патч невозможно, временной мерой служит отключение вложенной виртуализации через параметры kvm_intel.nested=0 для Intel или kvm_amd.nested=0 для AMD — это перекрывает путь атаки для недоверенных гостей. ARM64-хосты Januscape не касается, там действует отдельная история с ITScape и CVE-2026-46316. Любой x86-хост KVM с включённой вложенной виртуализацией и доступом недоверенных гостей стоит считать приоритетной целью для патчинга. Что касается публичного PoC, для его запуска нужен загружаемый модуль ядра внутри гостя, а сама гонка приводит к панике хоста за секунды или минуты работы.
Баг Ким отправил как zero-day в программу Google kvmCTF — контролируемую программу вознаграждений за поиск уязвимостей в KVM, где за полноценный побег из гостя на хост платят до 250 000 долларов. Опубликованный proof-of-concept вызывает панику ядра хоста — попросту говоря, крашит всю систему целиком со всеми виртуальными машинами на ней. Отдельный эксплойт, дающий полное выполнение кода на хосте, Ким пока не раскрывает.
Суть ошибки в том, как KVM управляет теневыми таблицами страниц — своей внутренней копией страничной таблицы гостя. Когда система решает переиспользовать страницу для отслеживания памяти, она сверяет только адрес этой страницы, но не её тип. А два разных типа страниц вполне могут делить один и тот же адрес, выполняя при этом совершенно разные функции. В результате внутренние записи KVM о том, кому какая память принадлежит, начинают путаться.
Из этой путаницы вытекают два сценария. Чаще всего ядро само обнаруживает повреждение данных и падает в панику — это защитный механизм, но он всё равно кладёт хост целиком вместе со всеми чужими виртуалками на нём. Реже происходит худший вариант: освобождённая страница переиспользуется до завершения очистки памяти, и процесс очистки пишет в память, которая ему уже не принадлежит. Атакующий контролирует, куда именно попадёт запись, хотя не полностью контролирует, что именно будет записано. Этого достаточно, чтобы довести атаку до произвольного выполнения кода на хосте. Само поведение бага одинаково на Intel и AMD, различается только финальный шаг эксплуатации — из-за архитектурных отличий процессоров.
Для атаки нужны две вещи: root внутри гостевой виртуальной машины (что нередкая ситуация на арендованных облачных инстансах) и включённая на хосте вложенная виртуализация. Здесь есть тонкость — даже хосты, которые по умолчанию используют аппаратные механизмы EPT или NPT, откатываются на устаревший программный shadow MMU, как только запускается nested virtualization. Именно в этом legacy-коде и сидит уязвимость. Участие QEMU или другого userspace-гипервизора не требуется — баг чисто внутри самого ядра KVM.
Ошибка была внесена коммитом 2032a93d66fa в августе 2010 года, во времена ядра линейки 2.6.36. Исправление — коммит 81ccda30b4e8 — попало в основную ветку 19 июня 2026 года. На практике под угрозой оказываются любые x86-системы, где размещаются недоверенные гостевые машины с включённой вложенной виртуализацией. Достаточно одной арендованной вредоносной виртуалки, чтобы уронить хост и все соседние машины на нём. А непубличный эксплойт Кима, если он реален, способен дать атакующему root на хосте — со всеми вытекающими последствиями для остальных гостей. Отдельная деталь касается RHEL и похожих дистрибутивов: там, где /dev/kvm открыт на запись для всех (режим 0666), тот же баг превращается в локальную эскалацию привилегий до root, хотя побег из гостя на хост считается более серьёзной проблемой.
Januscape — уже третье раскрытие уязвимостей ядра Linux от Кима примерно за два месяца. В мае 2026 года он опубликовал Dirty Frag (CVE-2026-43284 и CVE-2026-43500) — цепочку уязвимостей в работе с page cache, дающую детерминированный root-доступ на большинстве крупных дистрибутивов и продолжающую линию багов, начатую Dirty Pipe и Copy Fail. В июне того же года последовал ITScape (CVE-2026-46316) — первый публично продемонстрированный побег из гостя на хост на KVM/arm64, эксплуатирующий гонку в виртуальном контроллере прерываний. Januscape завершает эту серию как узкоспециализированная для x86 находка — proof-of-concept содержит отдельные пути кода для Intel и для AMD.
Стоит вспомнить, что программа kvmCTF от Google запущена в 2024 году именно потому, что KVM лежит в основе и Android, и Google Cloud. А в мае 2026 года уже фиксировалась похожая по природе, но технически иная проблема — CVE-2026-46113, тоже use-after-free в теневой страничной адресации x86 KVM, связанная с несовпадением rmap-записей. Получается, что за два месяца в одном и том же устаревшем участке кода нашли уже два разных use-after-free бага теневого MMU.
Исправление оказалось на удивление коротким — одна строка в функции kvm_mmu_get_child_sp(). Условие переиспользования страницы теперь проверяет не только номер гостевого фрейма (gfn), но и поле role.word, отвечающее за тип страницы. Страница переиспользуется, только если совпадают оба параметра. Автор патча — сопровождающий KVM Паоло Бонзини. Исправленные версии ядра вышли 4 июля 2026 года: 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211 и 5.10.260. Оценка по шкале CVSS от NVD пока не присвоена, но в рекомендациях прямо говорится — не ждать этой оценки, чтобы начать действовать.
Администраторам стоит проверить, включён ли в их x86-хостах коммит 81ccda30b4e8, причём смотреть лучше в changelog пакета, а не полагаться только на вывод uname -r — дистрибутивы нередко делают бэкпорты с собственной нумерацией версий. Если немедленно поставить патч невозможно, временной мерой служит отключение вложенной виртуализации через параметры kvm_intel.nested=0 для Intel или kvm_amd.nested=0 для AMD — это перекрывает путь атаки для недоверенных гостей. ARM64-хосты Januscape не касается, там действует отдельная история с ITScape и CVE-2026-46316. Любой x86-хост KVM с включённой вложенной виртуализацией и доступом недоверенных гостей стоит считать приоритетной целью для патчинга. Что касается публичного PoC, для его запуска нужен загружаемый модуль ядра внутри гостя, а сама гонка приводит к панике хоста за секунды или минуты работы.
