CVE-2026-64604 Overview
CVE-2026-64604 is a Linux kernel vulnerability in the Kernel-based Virtual Machine (KVM) subsystem for Intel Virtual Machine Extensions (VMX). The flaw resides in the vmx_update_cr8_intercept() function within arch/x86/kvm/vmx/vmx.c. When updating Control Register 8 (CR8) intercepts, the code invokes get_vmcs12() unconditionally, triggering a lockdep assertion during vCPU creation because the vCPU mutex is not yet held. The issue was surfaced by the syzkaller fuzzer and resolved by fetching vmcs12 only when the vCPU is in guest mode.
Critical Impact
The lockdep assertion in get_vmcs12() fires during kvm_arch_vcpu_create(), producing kernel warnings on hosts running nested virtualization workloads.
Affected Products
- Linux kernel with KVM Intel VMX support enabled
- Hosts running nested virtualization on Intel CPUs
- Distributions shipping the affected arch/x86/kvm/vmx/ code paths
Discovery Timeline
- 2026-08-06 - CVE-2026-64604 published to NVD
- 2026-08-06 - Last updated in NVD database
Technical Details for CVE-2026-64604
Vulnerability Analysis
The defect lives in the KVM VMX nested-virtualization logic. The function vmx_update_cr8_intercept() at arch/x86/kvm/vmx/vmx.c:6879 calls get_vmcs12() to access the guest's virtual Virtual Machine Control Structure. get_vmcs12() contains a lockdep assertion that requires either the vCPU mutex to be held or the KVM instance to have zero user references.
During kvm_vm_ioctl_create_vcpu(), the kernel path reaches kvm_vcpu_reset() and then kvm_lapic_reset(), which triggers apic_update_ppr() and ultimately vmx_update_cr8_intercept(). At this stage the vCPU mutex is not yet held, so the assertion fires and the kernel emits a WARNING backtrace.
The fix restricts the get_vmcs12() call to cases where the vCPU is already in guest mode. The commit message explicitly notes "No functional change intended," indicating the issue is a correctness and diagnostic problem rather than a memory-safety flaw.
Root Cause
The root cause is an unconditional call to get_vmcs12() from vmx_update_cr8_intercept() before locking preconditions are satisfied. The lockdep assertion debug_locks && !(lock_is_held(&(&vcpu->mutex)->dep_map) || !refcount_read(&vcpu->kvm->users_count)) catches this contract violation. This is a locking-discipline issue rather than an exploitable memory-corruption bug.
Attack Vector
A local user with permission to issue ioctl() calls on /dev/kvm and create vCPUs can reach the vulnerable code path. The syzkaller reproducer invokes KVM_CREATE_VCPU from user space to trigger the warning. The published data does not indicate remote reachability, code execution, or privilege escalation. Impact is limited to kernel log noise and potential secondary correctness concerns in future nested-virtualization changes that build on this code path.
The upstream fix is described in the kernel commits referenced by the Kernel commit 258ec63c0f28 and related backports. No verified proof-of-concept exploit is available beyond the syzkaller trace embedded in the CVE description.
Detection Methods for CVE-2026-64604
Indicators of Compromise
- Kernel WARNING entries in dmesg referencing get_vmcs12 at arch/x86/kvm/vmx/nested.h:60 or vmx_update_cr8_intercept+0x3de/0x4e0
- Stack traces containing kvm_lapic_reset, kvm_vcpu_reset, and kvm_arch_vcpu_create on hosts using KVM Intel
- Unexpected KVM warnings appearing during vCPU creation by virtualization management tools such as libvirt or qemu
Detection Strategies
- Parse host /var/log/kern.log or journalctl -k for the string get_vmcs12 and the associated lockdep assertion text
- Correlate warning events with processes invoking ioctl(KVM_CREATE_VCPU) via audit rules on /dev/kvm
- Track kernel version and vendor patch level across hypervisor fleets to identify hosts still exposed to the flaw
Monitoring Recommendations
- Enable CONFIG_PROVE_LOCKING and CONFIG_DEBUG_LOCKDEP in non-production kernels to surface latent locking violations
- Ingest hypervisor kernel logs into a central logging platform and alert on repeated KVM WARNING records
- Monitor /dev/kvm access with auditd rules and review which local accounts create vCPUs
How to Mitigate CVE-2026-64604
Immediate Actions Required
- Apply the upstream Linux kernel patches referenced in the CVE, including commit 258ec63c0f28 and the corresponding stable-tree backports
- Update to a distribution kernel that incorporates the fix for vmx_update_cr8_intercept()
- Restrict access to /dev/kvm to trusted users and virtualization service accounts only
Patch Information
The fix modifies vmx_update_cr8_intercept() so that get_vmcs12() is invoked only when the vCPU is in guest mode. Stable-tree backports are published across multiple kernel branches, including commits 3dcfb04dd43b, 570af5db081b, 7ef78d71ca71, 9a21f1defd96, c7cd3605244c, db8407b9fd06, and ffaaff82336d. Consult your distribution's security tracker for the specific package version that ships the fix.
Workarounds
- Disable nested virtualization on affected hosts by loading kvm_intel with nested=0 until the kernel is patched
- Limit local user access to KVM ioctls through Linux capabilities, SELinux, or AppArmor policies
- Reduce log noise by filtering the specific get_vmcs12 warning while patch rollout is in progress, without disabling lockdep globally
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
