Contact us
Articles › Security Advisories

Mitigating Zapscape (CVE-2026-64561) on Rocky Linux 8, 9, 10, and LTS Variants

cvesecuritykernelrocky linuxltsmitigationtroubleshootingkvmvirtualization

Arsalan Zaidi
Customer Support Engineer

Aug 06, 2026

Introduction

Zapscape (CVE-2026-64561) is a use-after-free vulnerability in the Linux kernel's KVM shadow MMU emulation. The flaw is in the mmu_page_zap_pte() function, which lacks proper root_count guards during shadow page reclamation. An untrusted KVM guest can exploit this to corrupt host kernel shadow pages, breaking guest-host isolation and enabling a guest-to-host escape. On Intel hosts, exploitation requires both EPT page walk lengths 4 and 5 to be exposed to L1 (a nested virtualization configuration). On AMD hosts, no such constraint exists. Public proof-of-concept code is available.

Problem

Zapscape affects any Linux system running KVM with the vulnerable kernel code present. The risk is highest on hosts that run untrusted guest workloads or enable nested virtualization. Exploitation requires guest-side code execution but no special privileges within the guest.

Treat the following CIQ product variants as affected unless they are running a patched kernel listed in the Patched Kernels section:

  • RLC Pro LTS 8.6 and 8.8 variants
  • RLC Pro LTS 9.2, 9.4, and 9.6 variants
  • RLC Pro FIPS 9.2 and 9.6 variants
  • CIQ SIG/Cloud Next 10
  • CIQ Linux Kernel LT 6.12
  • CIQ Linux Kernel 6.18

The following are not affected:

  • CIQ Bridge 7.9 and CentOS 7: the vulnerable code was not present in the 3.10 kernel
  • Rocky Linux 8.10 (Community): the fix is included in the current release kernel (4.18.0-553.148.1.el8_10)
  • Rocky Linux 9.8 (Community): the fix is included in the current release kernel (5.14.0-687.31.1.el9_8)

Systems that do not use KVM (no kvm or kvm_intel/kvm_amd modules loaded) are not exposed to this vulnerability regardless of kernel version.

Status

  • Patched kernels are available for RLC Pro LTS, FIPS, and SIG/Cloud Next variants. See the Patched Kernels table below.
  • CIQ Linux Kernel (CLK) 6.12 and 6.18 patched builds are in progress and will be available shortly.
  • Disabling nested virtualization reduces the attack surface on Intel hosts. See the Mitigation section.
  • Rocky Linux 8 and 9 community editions are already protected in their current release kernels.
  • CIQ Bridge 7.9 and CentOS 7 are not affected.
  • Open a support case if you need help assessing exposure or tracking patched kernel availability for a specific CIQ variant.

Patched Kernels

Variant Patched Kernel Version Repo Released
RLC Pro LTS 8.6 kernel-4.18.0-372.32.1.el8_6.86ciq_lts.17.1 rlc-8.6-lts.x86_64 2026-08-05
RLC Pro LTS 9.2 kernel-5.14.0-284.30.1.el9_2.92ciq_lts.14.2 rlc-9.2-lts.x86_64 2026-08-06
RLC Pro LTS 9.6 kernel-5.14.0-570.60.1+21.1.el9_6_ciq rlc-9.6-lts.x86_64 2026-08-05
RLC Pro FIPS 9.2 kernel-5.14.0-284.30.1.el9_2.ciqfips.0.21.1 fips-9.2-compliant-x86_64 2026-08-06
RLC Pro FIPS 9.6 kernel-5.14.0-570.60.1+21.1.el9_6_ciq fips-9.6-compliant-x86_64 2026-08-05
CIQ SIG/Cloud Next 10 kernel-6.12.0-211.43.1+2.1.el10_2_ciq ciq-scn-10.x86_64 2026-08-05

CIQ updates this table as tested kernels become available for each variant.

Variant Status
CIQ Linux Kernel LT 6.12 Pending
CIQ Linux Kernel 6.18 Pending

Confirm what is running on a given system with:

uname -r

Installing the Update

RLC Pro LTS, FIPS, and SIG/Cloud Next

sudo dnf update kernel*

Reboot into the new kernel after the update completes. No additional repository configuration is needed; the update is available from the configured CIQ repository. If the update does not appear, run sudo dnf clean all && sudo dnf makecache to refresh repository metadata.

CIQ Linux Kernel (CLK) Variants

sudo dnf update kernel-clk*

Reboot into the new kernel. CLK patched kernels will be available once the build promotion completes.

Community Edition (RESF)

sudo dnf update kernel*

Reboot into the new kernel. Rocky Linux 8 and 9 community editions already include the fix in their current release kernels.

Mitigation

The vulnerability is in the KVM shadow page table code path (mmu_page_zap_pte()), which is exercised primarily through nested virtualization. On modern hardware, direct guest translations use EPT (Intel) or NPT (AMD), so the shadow MMU code path is largely dormant for non-nested workloads.

Disabling nested virtualization

If nested virtualization is not required, disabling it eliminates the primary attack surface. This is effective on Intel hosts, where the exploit requires nested EPT page walk configuration. On AMD hosts, the vulnerability can also be triggered without nested virtualization, so this mitigation provides reduced protection on AMD platforms.

For Intel hosts:

echo "options kvm_intel nested=0" | sudo tee /etc/modprobe.d/kvm-no-nested.conf
sudo modprobe -r kvm_intel && sudo modprobe kvm_intel

For AMD hosts:

echo "options kvm_amd nested=0" | sudo tee /etc/modprobe.d/kvm-no-nested.conf
sudo modprobe -r kvm_amd && sudo modprobe kvm_amd

Unloading the KVM module (modprobe -r) requires shutting down all running VMs first. Plan a maintenance window before applying this change on production hypervisors. For a reboot-based approach, create the modprobe config file and reboot during a scheduled maintenance window instead.

Verify nested virtualization is disabled:

cat /sys/module/kvm_intel/parameters/nested   # Intel
cat /sys/module/kvm_amd/parameters/nested     # AMD

Output should be N or 0.

If nested virtualization is required

If nested virtualization cannot be disabled, the only effective mitigation is updating to a patched kernel. In the interim, restrict KVM access to trusted users and audit which guests have nested virtualization enabled.

Verification

To verify whether a system is running a patched kernel:

uname -r

Compare the output against the Patched Kernels table above. If the running kernel version matches or is newer than the patched version listed for your variant, the fix is in place.

To check whether a system is running KVM and could be exposed:

lsmod | grep kvm

If no output is returned, KVM is not loaded and the system is not exposed regardless of kernel version.

To check whether nested virtualization is currently enabled:

cat /sys/module/kvm_intel/parameters/nested 2>/dev/null || \
cat /sys/module/kvm_amd/parameters/nested 2>/dev/null

Resolution

  1. Update the kernel: sudo dnf update kernel* (or kernel-clk* for CLK variants)
  2. Reboot into the new kernel
  3. Verify the running kernel with uname -r
  4. If nested virtualization was disabled as a temporary measure and is needed, re-enable it by removing /etc/modprobe.d/kvm-no-nested.conf and reloading the KVM module or rebooting

Notes

  • On Intel hosts, the exploit requires both EPT page walk lengths 4 and 5 exposed to L1, which is a nested virtualization configuration. Hosts running only direct (non-nested) guests on Intel are at lower risk.
  • On AMD hosts, the vulnerability can be triggered without nested virtualization, making the attack surface broader on AMD platforms.
  • Systems not running KVM at all (bare-metal workloads, container-only hosts) are not affected regardless of kernel version.
  • The proof-of-concept requires only unprivileged code execution within a guest VM. No special kernel modules or guest-side privileges are needed.

CVE-2026-64561 on NVD

CVE-2026-64561 on MITRE

Zapscape disclosure on oss-security