CVE-2026-46071

What it actually does

CVE-2026-46071 affects the Linux kernel KVM implementation for AMD SVM nested virtualization. During nested SVM VM-exit handling, KVM copied Last Branch Record state into the nested VMCB and incorrectly marked the destination VMCB_LBR field dirty. Clearing or changing clean bits in the guest-provided vmcb12 is not architecturally defined and can lead to undefined nested-virtualization behavior. The practical impact is availability loss: a local user with sufficient ability to run or influence nested KVM/SVM workloads may be able to trigger KVM instability, guest failure, or potentially a host kernel crash. The issue is not described as enabling data theft, privilege escalation, or code execution.

Why it matters to the business

Organizations using Linux KVM with AMD nested virtualization are most exposed, especially virtualization platforms, CI systems, lab environments, and cloud-like services that allow users to run nested hypervisors. Successful exploitation could interrupt virtual machine workloads or destabilize the host, causing service downtime and operational disruption. The risk is currently moderated by low EPSS, no CISA KEV listing, no known ransomware use, and no reported exploit maturity, but kernel availability issues should still be prioritized where untrusted or semi-trusted users can run nested virtualization workloads.

How an attack unfolds

An attacker first needs local access to a system or VM context where AMD KVM nested virtualization is enabled and where they can run or control nested SVM activity. They then create or manipulate a nested virtualization workload that causes repeated nested VM exits involving Last Branch Record state handling. During the vulnerable path, KVM copies LBR state into the nested VMCB and incorrectly changes VMCB clean-bit state in vmcb12. Because this state transition is architecturally undefined, the attacker may be able to induce unstable KVM behavior, guest crashes, or host kernel failure. The expected attacker objective is denial of service rather than persistence, credential theft, or remote compromise.

How to fix it

Upgrade the Linux kernel to a vendor-supported version that includes the upstream KVM nSVM fix for this issue. Because no exact fixed versions were provided, use the security advisory from the relevant Linux distribution or kernel vendor to identify the corrected package. Prioritize systems using AMD processors with KVM nested virtualization enabled. If immediate patching is not possible, reduce exposure by disabling nested virtualization for AMD KVM, for example by setting the kvm_amd module option nested=0 through the appropriate modprobe configuration and rebooting or reloading the module during a maintenance window. Also restrict the ability to run nested hypervisors to trusted administrators and isolate workloads that require nested virtualization.

How to confirm the fix worked

Confirm the running kernel version matches a vendor release that contains the fix. Validate that the updated kernel is actually booted, not merely installed. On AMD KVM hosts, check whether nested virtualization is enabled by reviewing /sys/module/kvm_amd/parameters/nested; a value indicating disabled status can be used as a mitigation validation where patching is pending. Review kernel package changelogs or vendor advisories for references to the KVM nSVM VMCB_LBR or svm_copy_lbrs fix. After remediation, run representative nested-virtualization workloads and monitor dmesg, journald, and hypervisor logs for KVM, kvm_amd, Oops, BUG, panic, or VM-exit related errors.

Typical attack path

1. Gain local authenticated access to a Linux system or guest environment where AMD KVM nested virtualization is available.
2. Confirm that the kvm_amd module is loaded and nested virtualization is enabled.
3. Launch or control a nested hypervisor workload using AMD SVM/nSVM functionality.
4. Trigger nested VM exits that exercise KVM LBR state-copying behavior.
5. Cause undefined VMCB clean-bit handling in the vulnerable kernel path.
6. Induce VM instability, KVM failure, or host availability impact.

How to detect it

Look for evidence of attempted or successful denial of service on Linux KVM hosts, especially AMD systems with nested virtualization enabled. Useful log sources include the kernel ring buffer, system journal, syslog, hypervisor management logs, VM lifecycle logs, and crash dump infrastructure such as kdump or apport where applicable. Investigate unexplained host reboots, kernel panics, KVM module faults, guest crashes correlated with nested virtualization activity, or repeated nested VM start/stop events. Search for kernel messages involving kvm_amd, nested SVM, nSVM, VMCB, LBR, Oops, BUG, general protection faults, NULL pointer dereferences, soft lockups, hard lockups, and panic events. There are no public exploit-specific network indicators for this issue, and exploitation is expected to be local rather than remote over the network.

• kvm_amd
• nested_svm_vmexit
• svm_copy_lbrs
• VMCB_LBR
• vmcb12
• nSVM
• nested SVM
• KVM: nSVM
• kernel BUG
• BUG: kernel NULL pointer dereference
• Oops:
• general protection fault
• Kernel panic
• soft lockup
• hard lockup
• /sys/module/kvm_amd/parameters/nested
• /var/crash/
• /proc/vmcore

What your security team should do

• Inventory Linux KVM hosts using AMD processors and identify where nested virtualization is enabled.
• Patch affected systems to a vendor-supported kernel containing the KVM nSVM fix, prioritizing multi-tenant, CI, lab, and virtualization-host environments.
• Where patching is delayed, disable AMD KVM nested virtualization unless it is explicitly required.
• Restrict nested virtualization access to trusted users and workloads until remediation is complete.
• Monitor kernel and hypervisor logs for KVM/kvm_amd crashes, kernel Oops events, panic messages, and unusual nested-virtualization failures.
• Because there is no KEV listing, no known ransomware use, and very low EPSS, treat this as a targeted availability hardening item rather than an internet-scale emergency, unless nested virtualization is exposed to untrusted users.