Skip to main content
Version: Next

Zapscape (CVE-2026-64561)

VM-to-host escape

Zapscape is a VM-to-host escape in the Linux kernel's KVM/x86 subsystem. A tenant who has root inside their own VM can, under the right conditions, gain root on the hypervisor and therefore over every other VM on that host. Because VirtFusion hypervisors run tenant workloads on KVM, any affected hypervisor should be patched and rebooted as a priority.

Summary​

FieldDetail
CVECVE-2026-64561
NicknameZapscape (part of "The KVM Escape Trilogy", alongside ITScape and Januscape)
ComponentLinux kernel, KVM/x86 shadow MMU
ClassUse-after-free (UAF)
ImpactVM-to-host escape, leading to arbitrary code execution as root on the host
SeverityImportant. CVSS 3.1 base score 7.0
Upstream fixCommit 2abd5287f083 (merged mainline 2026-07-21)
Where it appliesHypervisors running KVM VMs. This does not affect the VirtFusion control server.

Am I affected?​

The vulnerability lives in the host kernel on your hypervisors. It is not a VirtFusion application flaw and does not affect the control server. You are potentially exposed if all of the following are true:

  • A hypervisor runs an unpatched Linux kernel that includes the vulnerable shadow-MMU code (introduced in the 5.9 era via commit f95eec9bed76).
  • VMs are able to use nested virtualization (nested VMX/EPT on Intel, or nested SVM/NPT on AMD).
  • The VM is controlled by an untrusted party with root inside the VM, which is the normal situation in a multi-tenant hosting environment.

On Intel hosts an extra condition applies: exploitation requires both 4-level and 5-level EPT page-walk support to be exposed to the L1 VM. AMD hosts have no such extra condition.

Technical details​

The bug is a use-after-free in KVM's shadow MMU, on the recursive "zap" path used during shadow-page reclamation.

Two page-fault paths validate the shadow root before reclaiming shadow pages instead of after. When a single kvm_mmu_page is aliased as both a child of one nested page table and the pinned root of another, quota-driven reclamation can recursively prepare (and free) that page through its parent without the root_count protection applying. KVM then keeps building mappings beneath a root that reclamation has already invalidated, leaving dangling pointers that allow writes to freed memory. From there the public proof-of-concept chains a KASLR leak and a usermode-helper callback to run arbitrary code as root on the host.

The upstream fix (2abd5287f083) moves the stale-root check to after make_mmu_pages_available(), so KVM restarts the fault if the root became invalid during reclamation rather than continuing to use freed structures.

Patch status by distribution​

VirtFusion is supported on Debian 12/13, Ubuntu 22.04/24.04, and RHEL-family 9/10 (AlmaLinux / Rocky). The table below tracks the fix for those distributions.

This is a point-in-time snapshot

The state below reflects 2026-08-08. Distribution patch status changes daily as errata ship. Always confirm against the vendor's live security tracker (linked in References) before deciding a host is safe.

DistributionStatusFixed kernel / advisory
Debian 13 (trixie)Patchedlinux 6.12.101-1 (DSA-6415-1)
Debian 12 (bookworm)Not yet fixedPatch in review; monitor the Debian tracker
Ubuntu 24.04 LTS (noble)Not yet fixedPatch prepared, in validation
Ubuntu 22.04 LTS (jammy)Not yet fixedPatch prepared, in validation
RHEL 9 / AlmaLinux 9 / Rocky 9Patchedkernel-5.14.0-687.30.1.el9_8 or newer (shipped 2026-07-22; AlmaLinux via ALSA-2026:19225)
RHEL 10 / AlmaLinux 10 / Rocky 10Rolling outFix in preparation for el10; verify against your vendor's errata

Debian​

  • Debian 13 (trixie): Fixed in linux 6.12.101-1 (DSA-6415-1). Update and reboot.
  • Debian 12 (bookworm): No fixed kernel published yet at the time of writing. Apply the interim mitigations and watch the tracker, then install the security update as soon as it lands.

Ubuntu​

  • Ubuntu 24.04 LTS (noble) and 22.04 LTS (jammy): No fixed linux package released yet at the time of writing; patches were prepared and in validation. This covers the cloud and derivative kernels too (linux-kvm, linux-aws, linux-azure, linux-gcp, linux-oracle, FIPS variants, and so on). Apply the interim mitigations and update once the USN is published.

RHEL family (AlmaLinux / Rocky)​

  • 9 (el9): Fixed. Install kernel-5.14.0-687.30.1.el9_8 or newer and reboot. AlmaLinux ships this as ALSA-2026:19225; Rocky publishes the equivalent RLSA. RHEL 8 was also fixed (kernel-4.18.0-553.147.1.el8_10 or newer) if you run any el8 hosts.
  • 10 (el10): The el10 kernel fix was still rolling out at the time of writing. Check the AlmaLinux / Rocky errata for your exact point release and install the fixed kernel when available. Apply the interim mitigations in the meantime.

Remediation​

The fix is a host kernel update followed by a reboot on every hypervisor. A kernel update does not take effect until the host is running the new kernel, so the reboot is required.

apt-get update -y && apt-get install --only-upgrade linux-image-amd64 -y
# Reboot into the new kernel once VMs are migrated/stopped:
reboot

After rebooting, confirm the host is running a fixed kernel:

uname -r

Compare the output against the fixed version in the table above.

Mitigations if you cannot patch yet​

If a fixed kernel is not yet available for a host, reduce exposure until you can update.

Disable nested virtualization on hypervisors that do not need it. This removes the primary exploitation path. VirtFusion uses the stock distribution libvirt/KVM, and on current kernels the nested module parameter defaults to enabled for both kvm_intel and kvm_amd, so hosts are exposed by default.

The nested parameter cannot be changed while kvm_intel / kvm_amd is loaded, and the module cannot be unloaded while any VM is running. The reliable sequence is therefore to set the value in the modprobe.d config, then reboot the host so the module reloads with nested=0.

Nested can be enabled two ways: by an active options ... nested=1 line in a modprobe.d file, or, when nothing sets it, by the kernel module's own default (which is nested=1 on current kernels). Handle whichever applies. When you do set it in a file, correct the value at its source rather than adding a second override file: modprobe reads every .conf file in the modprobe.d directories in lexicographic filename order and the last value for a repeated parameter wins, and a plain name like kvm.conf sorts after any numeric-prefixed file, so a separate override is easily outranked.

First, find any active (uncommented) line that sets nested. Commented example lines, such as those AlmaLinux ships in /etc/modprobe.d/kvm.conf, do not count:

grep -RHn '^[^#]*nested' /etc/modprobe.d/ /run/modprobe.d/ /usr/lib/modprobe.d/ /lib/modprobe.d/ 2>/dev/null

If an active line sets nested=1 (some VirtFusion hosts ship /etc/modprobe.d/kvm.conf this way), change its value to 0:

sed -i 's/nested=1/nested=0/' /etc/modprobe.d/kvm.conf

If the command returns nothing, nested is on by the kernel default and no file is setting it. Add an active line that disables it, matching your host's CPU vendor:

echo "options kvm_intel nested=0" >> /etc/modprobe.d/kvm.conf

The change only takes effect once the module reloads, which means a reboot:

reboot

After the host is back up, confirm nested virtualization is off. This sysfs value is the effective setting regardless of what produced it, so it is the definitive check. 0 means disabled:

cat /sys/module/kvm_intel/parameters/nested

If it still reads 1 after a reboot, the value is being forced on the kernel boot command line, which the modprobe.d config cannot override. Remove any kvm_intel.nested=1 / kvm_amd.nested=1 from your bootloader config (/etc/default/grub), regenerate the config, and reboot.

note

Disabling nested virtualization requires a host reboot, which is also what applies a kernel update. If a fixed kernel has already shipped for your distribution, it is simpler to patch and reboot once (see Remediation) instead. Turning off nested is intended for hosts where no fixed kernel is available yet. It lowers the likelihood of exploitation but does not remove the vulnerability.

References​

Last updated on