CVE-2026-64604 in Linux
Summary
by MITRE • 08/06/2026
In the Linux kernel, the following vulnerability has been resolved:
KVM: VMX: Grab vmcs12 on CR8 interception update iff vCPU is in guest mode
When updating CR8 intercepts, get vmcs12 if and only if the vCPU is in guest mode so that a future change can have update CR8 intercepts during vCPU creation, without running afoul of get_vmcs12()'s lockdep assertion.
------------[ cut here ]------------
debug_locks && !(lock_is_held(&(&vcpu->mutex)->dep_map) || !refcount_read(&vcpu->kvm->users_count)) WARNING: arch/x86/kvm/vmx/nested.h:61 at get_vmcs12 arch/x86/kvm/vmx/nested.h:60 [inline], CPU#0: syz.2.19/5879
WARNING: arch/x86/kvm/vmx/nested.h:61 at vmx_update_cr8_intercept+0x3de/0x4e0 arch/x86/kvm/vmx/vmx.c:6879, CPU#0: syz.2.19/5879 Modules linked in: CPU: 0 UID: 0 PID: 5879 Comm: syz.2.19 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:get_vmcs12 arch/x86/kvm/vmx/nested.h:60 [inline]
RIP: 0010:vmx_update_cr8_intercept+0x3de/0x4e0 arch/x86/kvm/vmx/vmx.c:6879 Call Trace: <TASK> apic_update_ppr arch/x86/kvm/lapic.c:984 [inline]
kvm_lapic_reset+0x1c24/0x2980 arch/x86/kvm/lapic.c:3023 kvm_vcpu_reset+0x44c/0x1bf0 arch/x86/kvm/x86.c:12986 kvm_arch_vcpu_create+0x746/0x8b0 arch/x86/kvm/x86.c:12847 kvm_vm_ioctl_create_vcpu+0x428/0x930 virt/kvm/kvm_main.c:4201 kvm_vm_ioctl+0x893/0xd50 virt/kvm/kvm_main.c:5159 vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK>
No functional change intended.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/06/2026
This vulnerability exists within the Linux kernel's KVM virtualization subsystem, specifically affecting the Intel VMX implementation when handling CR8 interception updates during nested virtualization scenarios. The issue manifests as a lockdep assertion failure that occurs when attempting to update CR8 intercepts during vCPU creation processes. The root cause stems from improper conditional logic in the vmx_update_cr8_intercept function where get_vmcs12() is called without verifying that the vCPU is actually operating within guest mode. This oversight triggers a lockdep warning because get_vmcs12() performs strict locking validation that expects certain mutex states to be properly held, yet during vCPU initialization this condition may not yet be met.
The technical flaw represents a violation of proper synchronization practices in concurrent kernel programming, specifically concerning the management of virtual machine control structures (VMCS) within nested virtualization contexts. When the kernel attempts to update CR8 intercepts during vCPU creation, it calls get_vmcs12() without checking if the vCPU is already in guest mode, which creates a race condition scenario that conflicts with the kernel's lock validation subsystem. This issue falls under CWE-362, which addresses concurrent execution using locks and resource sharing problems, and more specifically relates to improper locking mechanisms in virtualization contexts.
The operational impact of this vulnerability extends beyond simple assertion failures, as it can potentially lead to system instability during virtual machine creation processes when nested virtualization is active. The warning message indicates that the system detected an invalid lock state during a critical vCPU initialization sequence, which could result in kernel panics or unpredictable behavior in hypervisor environments. During normal operation, this vulnerability may not produce immediate functional issues since no actual change was intended as noted in the patch description, but it creates a dangerous precedent where future modifications to CR8 interception logic could trigger more severe failures.
Mitigation strategies should focus on implementing proper conditional checks before calling get_vmcs12() during CR8 interception updates. The fix ensures that vmcs12 is only retrieved when the vCPU is confirmed to be in guest mode, thereby avoiding premature lock acquisitions that would violate the kernel's lockdep assertions. This approach aligns with ATT&CK technique T1059.003 for system binary modification and addresses the underlying concurrency issue through proper state validation. Administrators should ensure their systems are updated with patches that implement this conditional logic, particularly in environments heavily reliant on nested virtualization or KVM-based hypervisor deployments.
The vulnerability demonstrates a classic example of improper resource management in virtualized environments where kernel developers must carefully consider the execution context when acquiring locks and managing shared resources. The fix represents a defensive programming approach that prevents potential future regressions while maintaining backward compatibility. This issue highlights the complexity of managing virtual machine control structures in nested virtualization scenarios, where the same code path may be executed during different phases of vCPU lifecycle management, requiring context-aware resource acquisition strategies to prevent lockdep violations and maintain system stability across various operational states.