CVE-2026-64562

What it actually does

This is a race condition in the Linux kernel KVM Intel nested virtualization path. When nested VMX is in use, KVM can free a shadow VMCS while another path still has a pointer to it and may later execute VMCLEAR after a vCPU scheduling migration. The likely impact is host-kernel memory misuse, such as use-after-free, kernel crash, or undefined behavior in the KVM module. Exploitation generally requires the attacker to control or influence a guest VM that is allowed to use nested virtualization on an affected Intel KVM host.

Why it matters to the business

Organizations running untrusted or multi-tenant virtual machines with nested virtualization enabled could face host instability or denial of service if a guest triggers this race. The risk is lower for systems that do not expose nested VMX to guests. EPSS is currently low, it is not in CISA KEV, and no public exploit maturity is reported, so this should be prioritized as a kernel virtualization hardening update rather than an emergency internet-facing exposure.

How an attack unfolds

An attacker first needs access to a VM running on an affected Linux KVM host where Intel nested virtualization is enabled. From inside that guest, the attacker creates or manipulates a nested VMX workload so that KVM allocates and tears down nested VMCS state. By repeatedly driving nested VM lifecycle operations while the host schedules or migrates the vCPU between physical CPUs, the attacker attempts to hit the race where free_nested() frees the shadow VMCS before the loaded VMCS clearing path has fully detached it. If successful, the host kernel may operate on stale VMCS state during VMCLEAR, potentially causing a KVM crash, kernel oops, panic, or other memory-corruption side effects.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that includes the KVM nVMX fix to hide the shadow VMCS immediately after VMCLEAR before the page is freed. Because no exact fixed package versions were provided, track vendor advisories for this CVE and update to the first fixed kernel release or later. Until patched, disable nested virtualization for untrusted guests, especially on Intel KVM hosts, for example by setting the kvm_intel nested parameter to disabled where operationally feasible. Where disabling nested virtualization is not possible, restrict nested VMX to trusted workloads, reduce multi-tenant exposure, and consider live-migrating sensitive workloads away from unpatched hosts before maintenance.

How to confirm the fix worked

Confirm the running kernel package includes the vendor fix for this issue, not only that an updated package is installed. Reboot into the fixed kernel if required. Verify nested virtualization exposure by checking the KVM Intel nested parameter, commonly /sys/module/kvm_intel/parameters/nested, and confirm that untrusted guests do not receive VMX/nested virtualization features. Review virtualization fleet configuration, templates, and CPU feature passthrough settings to ensure nested VMX is disabled or limited as intended. On patched hosts, monitor kernel logs during nested virtualization operations and confirm there are no KVM-related oops, panic, KASAN, or VMCS clearing errors.

Typical attack path

1. Obtain code execution inside a guest VM hosted on an affected Linux KVM system.
2. Confirm or require that Intel nested virtualization is exposed to the guest.
3. Run a nested-virtualization workload that repeatedly creates, clears, and destroys nested VMX state.
4. Induce timing pressure through rapid vCPU activity, CPU scheduling changes, or repeated nested VM entry/exit operations.
5. Trigger the race between freeing nested VMCS state and clearing the loaded VMCS pointer.
6. Cause host-side KVM instability such as kernel oops, panic, or VM-host denial of service.

How to detect it

Look for evidence of host-side KVM instability rather than remote network indicators. Useful sources include dmesg, journald, /var/log/kern.log, /var/log/messages, hypervisor management logs, crash dumps, kdump/vmcore artifacts, and monitoring alerts for unexpected host reboots. Focus on crashes or warnings involving kvm_intel, VMX, VMCS, VMCLEAR, nested virtualization, free_nested(), loaded_vmcs_clear(), or __loaded_vmcs_clear(). Correlate these events with guest workloads that use nested virtualization, repeated VM creation/destruction, or unusual guest CPU feature use. If kernel sanitizers are enabled, search for KASAN, slab, or use-after-free reports tied to KVM nVMX code paths. There are no known network-based indicators, named threat actors, or public exploitation campaigns associated with this issue based on the provided data.

• kvm_intel
• VMCLEAR
• VMCS
• shadow VMCS
• nested VMX
• free_nested
• loaded_vmcs_clear
• __loaded_vmcs_clear
• KASAN: use-after-free
• BUG: unable to handle kernel paging request
• BUG: kernel NULL pointer dereference
• kernel panic
• Oops:
• /sys/module/kvm_intel/parameters/nested

What your security team should do

• Inventory Linux KVM hosts using Intel nested virtualization and prioritize them for patching.
• Patch virtualization hosts to a kernel release containing the KVM nVMX shadow VMCS VMCLEAR fix; reboot into the fixed kernel.
• Temporarily disable nested virtualization for untrusted or multi-tenant guests until all affected hosts are fixed.
• Flag hosts exposing VMX/nested virtualization to guest workloads as higher priority than hosts where nested virtualization is disabled.
• Monitor host kernel logs for KVM, VMX, VMCS, use-after-free, oops, and panic events that coincide with guest nested virtualization activity.
• Because EPSS is low, KEV is false, and no public exploit maturity is reported, handle through accelerated maintenance rather than emergency incident response unless crash evidence is present.