КИБЕРБЕЗОПАСНОСТЬ

Google заплатила $250 тысяч за побег из гостевой VM в Linux

Google выплатила $250 тысяч за баг в Linux, который позволяет гостевой VM получить root на хосте. Исправления уже есть в ядре.

✍️ Редакция iTech News | 09.07.2026 | ⏱ 4 мин | Источник: Ars Technica
🔑

Google выплатила $250 тысяч за одну из самых неприятных уязвимостей Linux этого года: баг в KVM позволяет гостевой виртуальной машине вырваться на хост и получить там root-права. Для облаков, хостингов и любых команд, которые держат мультиарендные нагрузки на Linux, это не академическая страшилка, а прямой вопрос из серии «что будет, если один арендатор доберется до всей железки».

О находке CVE-2026-53359 сообщает Ars Technica. Уязвимость обнаружил исследователь Хюнву Ким, который назвал ее Januscape. Проблема живет в KVM — модуле виртуализации, встроенном в ядро Linux и используемом во множестве дистрибутивов. По описанию Кима, атакующему достаточно действий со стороны гостевой VM: при удачной эксплуатации он может либо уронить хостовое ядро и вместе с ним соседние виртуальные машины, либо выполнить код на хосте с правами root. Для публичных облаков это худший сценарий из возможных: один арендованный инстанс превращается в точку входа ко всему серверу.

Технически баг относится к классу use-after-free, то есть к ошибкам работы с памятью, когда код продолжает использовать уже освобожденный участок. В данном случае проблема связана с эмуляцией shadow MMU — механизма, который участвует в трансляции адресов памяти между гостевой системой, гипервизором и хостом. Эксплуатация повреждает shadow page на стороне хоста, а дальше уже открывается дорога либо к отказу в обслуживании, либо к захвату управления. Уязвимость затрагивает KVM на процессорах AMD и Intel, а в ядре она, по данным исследователя, незаметно прожила 16 лет. Ким опубликовал proof-of-concept, который запускается внутри гостевой машины и вызывает крах хоста. Полноценный эксплойт для побега из VM у него тоже есть, но публиковать его он пока не собирается.

Отдельно неприятно то, что проблема не завязана на QEMU. Это важная деталь для облачных платформ, которые используют собственные или сильно модифицированные стеки виртуализации. Если уязвимость сидит на стороне KVM, одного «у нас не совсем стандартная обвязка» недостаточно, чтобы выдохнуть. Правда, для атаки злоумышленнику нужны root-права внутри самой гостевой VM. Это не снижает серьезность, а скорее уточняет модель угроз: речь не о случайном пользователе веб-приложения, а о недоверенном арендаторе, подрядчике, исследователе или уже скомпрометированном workload, которому удалось стать root внутри инстанса.

На этом неделя для Linux не закончилась. Второй баг, CVE-2026-43499, получил имя GhostLock и тоже позволяет добраться до root, только уже не через побег из виртуальной машины, а через локальное повышение привилегий. Его нашли исследователи Nebula Security с помощью Vega, собственного AI-assisted сканера уязвимостей. Суть опять упирается в use-after-free: ошибка прячется в механизме futex priority inheritance, который нужен, чтобы важная задача не застревала из-за менее приоритетной. В редком сценарии отката блокировки очистка срабатывает не в тот момент и затирает запись не той задачи. В результате ядро продолжает доверять висячему указателю на память, которая уже освобождена и переиспользована. Дальше исследователи собирают из этого полноценную цепочку до выполнения кода с root-правами.

GhostLock выглядит чуть менее эффектно, чем побег из KVM, но для продакшена это не повод расслабляться. По шкале severity уязвимость получила 7,8 балла из 10, а корни проблемы тянутся в код futex, появившийся еще в 2011 году. Иными словами, речь идет не о каком-то экзотическом драйвере, который живет на трех стендах у энтузиастов, а о старом и активно используемом механизме ядра, который годами никто толком не перечитывал. Google выплатила за GhostLock $92 337 через программу kernelCTF. За Januscape награда заметно выше — те самые $250 тысяч, что неплохо отражает разницу в потенциальном масштабе последствий.

Для разработчиков и инфраструктурных команд выводы довольно приземленные. Во-первых, обе уязвимости Linux уже получили исправления в ядре, так что вопрос теперь не в наличии патча, а в скорости, с которой он доберется до конкретного дистрибутива, образа и managed-сервиса. Во-вторых, если у вас есть собственные облачные кластеры, bare metal с виртуализацией или внутренние платформы для команд, стоит не просто «обновить Linux», а отдельно проверить ветки ядра, на которых живут хосты KVM, и убедиться, что обновлены именно они. В-третьих, эта история еще раз показывает слабое место модной уверенности в изоляции: контейнеры, VM и sandbox действительно снижают риск, но не отменяют того факта, что один старый баг в ядре способен резко упростить жизнь злоумышленнику.

Сюжет здесь шире двух CVE и двух щедрых чеков от Google. Обе уязвимости Linux прожили в ядре 15-16 лет, а одну из них нашли с помощью AI-assisted инструмента. Это уже не выглядит как разовая сенсация. Скорее, отрасль входит в период, когда старый системный код будут активнее перекапывать и люди, и автоматизированные сканеры, а значит у админов, SRE и платформенных команд впереди не самый спокойный сезон патчей.

Поделиться: Telegram X LinkedIn