Xen — один из старейших гипервизоров, и его модель безопасности держится на том, что гостевая система не может выйти за пределы выданной ей памяти. Обе уязвимости бьют именно в этот механизм.
Проблема в операции grant copy, через которую гости обмениваются страницами памяти. Вредоносная ВМ может так сманипулировать разделением памяти, что получит доступ к данным, которые ей не принадлежат: читать и, что хуже, писать в память других гостей и dom0 — управляющего домена. Для хостинга с арендованными виртуалками это означает риск побега из ВМ и потенциального захвата хоста.
Кто нашёл
Уязвимости обнаружили в Anthropic с помощью модели Claude, а проверил Стефан Липп из Ada Logics. Формулировка Xen осторожная: уровень доступа, который нужен атакующему внутри ВМ, в advisory не описан. Активной эксплуатации не зафиксировано.
С патчами сложнее
Затронуты Xen 4.6 и новее; 4.5 и старше не уязвимы. Исправления вышли для xen-unstable и веток до 4.19.x, а также для 4.18.x и 4.17.x. А вот для версий с 4.6 по 4.16 патчей нет — эти ветки уже вне поддержки. Если на хосте стоит такая версия, обновление невозможно в принципе, и остаётся только планировать миграцию.
Что делать
Сначала выяснить, какая версия Xen работает и поддерживается ли она. Если да — обновить и, по возможности, ограничить доверие между гостевыми системами: не держать на одном хосте ВМ разных арендаторов без необходимости.
Если версия из неподдерживаемого диапазона — это уже не задача патч-менеджмента, а задача миграции. Пока её нет, снижайте ставки: изолируйте хост, уберите с него чужие нагрузки и следите за целостностью dom0.
Xen is one of the oldest hypervisors, and its security model rests on a guest being unable to reach memory outside what it was given. Both flaws strike exactly that mechanism.
The problem is in the grant copy operation, through which guests exchange memory pages. A malicious VM can manipulate memory sharing so that it reaches data it does not own: reading and, worse, writing into the memory of other guests and dom0, the control domain. For hosting with rented virtual machines this means a risk of VM escape and potential host takeover.
Who found it
The flaws were discovered at Anthropic using Claude and validated by Stephan Lipp of Ada Logics. Xen’s wording is cautious: the advisory does not describe the access level an attacker needs inside the VM. No active exploitation has been recorded.
Patches are the harder part
Xen 4.6 and later are affected; 4.5 and earlier are not. Fixes shipped for xen-unstable and branches through 4.19.x, and for 4.18.x and 4.17.x. For versions 4.6 through 4.16, however, there are no patches — those branches are out of support. If a host runs one of them, updating is impossible in principle, and only migration remains.
What to do
First establish which Xen version is running and whether it is still supported. If it is, update, and where possible limit trust between guests: do not co-locate VMs from different tenants on one host without need.
If the version is in the unsupported range, this is no longer a patch-management task but a migration one. Until it happens, reduce the stakes: isolate the host, move other workloads off it, and watch the integrity of dom0.