4 августа в базе NVD появилась запись CVE-2026-64561, а 6 августа исследователь опубликовал разбор и proof-of-concept под именем Zapscape. Суть в одной строке: гость с правами root внутри виртуальной машины при определённых условиях может выполнить код в ядре хоста или уронить его целиком — вместе со всеми соседними ВМ.
Ниже — разбор в формате «вопрос — ответ». Вопросы взяты те, которые реально задают админы, а не те, которые красиво смотрятся в пресс-релизе.
Что вообще сломалось?
Официальная формулировка из ядерного changelog звучит так: «KVM: x86: Check for invalid/obsolete root after making MMU pages available». По-человечески: в теневом MMU (shadow MMU) подсистемы KVM/x86 порядок двух проверок оказался перепутан.
Когда KVM не хватает страниц для теневых таблиц, он запускает reclaim — освобождает страницы. Этот процесс может пометить текущий корневой каталог таблиц как невалидный. Проблема в том, что проверка «а корень ещё живой?» выполнялась до reclaim, а не после. В результате KVM продолжал работать с уже освобождённым корнем и мог писать в освобождённую память — классический use-after-free.
Нарушался и внутренний инвариант: невалидная страница не должна оказываться в списке активных, а тут к ней спокойно прицеплялись дочерние теневые страницы.
Ошибка живёт в ядре с коммита f95eec9bed76 от 8 июля 2020 года, то есть примерно с Linux 5.9. Исправлена коммитом 2abd5287f083, попавшим в upstream 21 июля 2026 года. Пять лет тихой жизни — обычная биография для бага в MMU.
Насколько это страшно по цифрам?
Red Hat в предварительной оценке поставил CVSS 3.1 = 7.0 и классифицировал как Important, CWE-825 (Expired Pointer Dereference). NVD на момент публикации этой заметки собственный балл ещё не проставил — в карточке CVE все три поля CVSS пустые.
Так что 7.0 — это оценка одного вендора, а не консенсус. Но практический потолок воздействия описан прямо в публикации исследователя: DoS всего физического сервера или выполнение кода с правами root на хосте.
Меня это касается? Условия срабатывания
Здесь и находится главное, что отличает Zapscape от «очередной CVE в ядре». Атака требует вложенной виртуализации: атакующему нужны права уровня ядра внутри гостевой ВМ (L1), чтобы поднять внутри неё ещё одну ВМ (L2) и через неё дотянуться до теневого MMU хоста.
Дальше начинаются архитектурные нюансы:
- AMD (SVM/NPT) — путь прямой, дополнительных условий нет.
- Intel (EPT) — гостю L1 должны быть отданы обе длины обхода страниц, 4-уровневая и 5-уровневая. Это заметно сужает поверхность: пятиуровневые таблицы — это Ice Lake-SP и новее.
Отдельная, независимая от вложенности дорожка — машины, где /dev/kvm открыт всем подряд (права 0666). Там это работает уже не как побег из ВМ, а как локальное повышение привилегий: любой пользователь на хосте может дойти до ядра. Проверить: ls -l /dev/kvm.
Как понять за минуту, включена ли у меня вложенность?
# Intel
cat /sys/module/kvm_intel/parameters/nested
# AMD
cat /sys/module/kvm_amd/parameters/nested
# Y или 1 — модуль вложенность разрешает
Важная тонкость: разрешение на уровне модуля ещё не значит, что конкретный гость её получил. Гостю нужен флаг vmx (Intel) или svm (AMD) в его виртуальном CPU. В Proxmox это происходит, когда типом процессора выбран host или флаг добавлен явно. Проверить изнутри гостя:
grep -oE '(vmx|svm)' /proc/cpuinfo | sort -u
Пусто — значит, этой ВМ вложенность не отдана, и вектор L1 → L2 для неё закрыт.
Какие ядра уже исправлены?
По данным NVD, фикс вошёл в стабильные ветки 6.6.148, 6.12.101, 6.18.42, 7.1.6 и в 7.2-rc5. Релиз LTS-ядер 6.18.42 / 6.12.101 / 6.6.148 подтверждён независимо в анонсах stable-веток.
Для дистрибутивов: по публикации TuxCare, RHEL 8 закрыт начиная с 4.18.0-553.147.1.el8_10 (23 июля), RHEL 9 — с 5.14.0-687.30.1.el9_8 (22 июля).
По Proxmox: в официальном форуме сотрудник компании назвал исправленные сборки — proxmox-kernel-6.8.12-40-pve и ядро 7.0.14-9 — и подтвердил, что пакеты выложены в pve-no-subscription.
Порядок действий для владельца гипервизора:
uname -r— сравнить с номерами выше.apt update && apt full-upgrade(илиdnf update), затем перезагрузка: ядро на лету не подменяется, если у вас нет live-patching.- На Proxmox —
pveversion -vи проверить, что загрузилось именно новое ядро, а не старое из первой позиции загрузчика. ls -l /dev/kvm— права должны быть660 root:kvm, а не666.
А если обновиться прямо сейчас нельзя?
Самое прямое временное решение — убрать условие срабатывания, то есть отключить вложенную виртуализацию:
# /etc/modprobe.d/kvm-nested.conf
options kvm_intel nested=0
# или
options kvm_amd nested=0
Затем update-initramfs -u и перезагрузка (либо выгрузка/загрузка модуля, если ни одна ВМ не запущена).
Не считайте отключение вложенности заменой обновлению. Это снятие одного условия эксплуатации, а не устранение use-after-free. Второй путь — через открытый /dev/kvm — этой мерой не закрывается вообще.
Побочный эффект честно: у вас перестанут работать вложенные гипервизоры, Docker Desktop и WSL2 внутри ВМ, Android-эмуляторы с аппаратным ускорением и любые тестовые стенды «Proxmox внутри Proxmox». Для большинства домашних лаб это терпимо на несколько дней, для CI-фермы — нет.
Есть ли эксплуатация «в дикой природе»?
На момент публикации подтверждённых случаев не сообщалось. PoC опубликован, но, по описанию самого исследователя, требует адаптации под конкретную цель — это не «скачал и запустил».
Практический вывод: паника не нужна, но и «подожду до следующего окна обслуживания» — плохая ставка, если вы сдаёте мощности другим людям. Формула риска простая: чужой root внутри вашей ВМ + отданная ему вложенность = обновляйтесь сегодня. Все ВМ ваши и вложенность не используется — обновляйтесь в плановом порядке.
Что это говорит об аренде VPS вообще
Полезное напоминание для тех, кто арендует: изоляция ВМ — это гарантия, которая держится на коде гипервизора, а он такой же смертный, как и всё остальное. Соседа по железу вы не выбираете и не проверяете.
Отсюда два практических следствия. Первое: то, что не должно утечь никогда — ключи, бэкапы, база с персональными данными — лучше держать на шифрованных томах, которые не смонтированы постоянно, чтобы дамп памяти хоста дал злоумышленнику меньше. Второе: спрашивайте у хостера политику обновления ядер. Провайдер, который перезагружает гипервизоры раз в полгода, — это отдельный класс риска, никак не отражённый в цене.
Источники
- CVE-2026-64561 — NVD
- Zapscape — публикация исследователя (V4bel)
- Phoronix: Zapscape Is The Latest Linux Vulnerability For KVM Guest-To-Host Escape, LPE
- The Hacker News: New Zapscape KVM Flaw Could Let Privileged L1 Guest Code Escape to Linux Hosts
- TuxCare: CVE-2026-64561 Zapscape KVM Flaw Explained
- Обсуждение в официальном форуме Proxmox
- Debian Security Tracker: CVE-2026-64561
Отключали ли вы вложенную виртуализацию на своих хостах — и что при этом отвалилось? И отдельный вопрос к тем, кто арендует VPS: ваш хостер вообще как-то уведомляет о перезагрузках гипервизора ради ядерных патчей, или вы узнаёте об этом по графику аптайма?