CVE-2026-46032

What it actually does

This is a Linux kernel KVM vulnerability in AMD nested virtualization support. During a nested SVM VM exit, KVM may fail to restore the L1 guest CR3 value. Before the fix, that failure path could be ignored by callers, allowing the L1 virtual CPU to continue running with corrupted CPU/MMU state instead of being shut down cleanly. The practical impact is denial of service: a local attacker with access to KVM/nested virtualization capabilities may be able to crash, hang, or destabilize the affected virtual CPU, guest, or virtualization stack. The issue is not described as enabling data theft, privilege escalation, or code execution.

Why it matters to the business

Systems that host virtual machines with KVM, especially those permitting nested virtualization on AMD CPUs, may be susceptible to workload disruption. A tenant, local user, test workload, or compromised VM with the right virtualization access could trigger instability that interrupts guest workloads and may require VM or host remediation. The CVSS score is moderate, EPSS is very low, it is not in CISA KEV, and no exploit maturity is reported, so broad active exploitation is not currently indicated; however, availability impact can still matter for virtualization platforms, CI environments, cloud hosts, and lab infrastructure that expose nested KVM.

How an attack unfolds

An attacker first needs local access to a system or guest context that can use KVM and nested AMD SVM virtualization. They then create or control a nested virtualization scenario, such as running an L1 hypervisor and an L2 guest. By manipulating nested guest execution so that a nested VM exit occurs while restoration of the L1 CR3 host state fails, the vulnerable kernel may mishandle the error path. Instead of treating the condition like hardware shutdown behavior and stopping the faulty vCPU, vulnerable KVM code can continue execution with corrupted vCPU state. The attacker’s objective is to induce a denial-of-service condition, such as guest crash, vCPU failure, KVM instability, or broader host workload disruption depending on kernel behavior and deployment configuration.

How to fix it

Upgrade the Linux kernel to a vendor release that includes the upstream KVM nSVM fix for this issue. No exact fixed package versions were provided in the input, so use the security advisory from the relevant distribution or kernel vendor and apply the first kernel version that includes the CVE-2026-46032 fix. After installing the patched kernel, reboot into the new kernel and verify the old vulnerable kernel is no longer running. If immediate patching is not possible, reduce exposure by disabling nested virtualization where it is not required, restricting access to /dev/kvm to trusted users and service accounts only, avoiding untrusted nested hypervisor workloads, and isolating systems that allow tenant-controlled nested virtualization.

How to confirm the fix worked

Confirm the running kernel version is a vendor-fixed build, not merely that a patched package is installed. Validate with commands such as uname -r, package-manager kernel version checks, and vendor advisory mapping for the fixed release. On AMD KVM hosts, check whether nested virtualization is enabled through /sys/module/kvm_amd/parameters/nested. Review permissions and group membership for /dev/kvm to ensure only trusted users can access hardware virtualization. Where possible, run a controlled nested virtualization regression test after patching to confirm nested SVM workloads still function and no kernel warnings, VM crashes, or KVM errors occur during nested VM exits. If nested virtualization is not required, verify it is disabled and remains disabled after reboot.

Typical attack path

1. Gain local access to a Linux system or VM that exposes KVM virtualization features.
2. Confirm AMD KVM nested virtualization is available, typically through the kvm_amd module with nested virtualization enabled.
3. Launch or control an L1 guest hypervisor and an L2 nested guest workload.
4. Trigger nested SVM VM exits under conditions that cause restoration of the L1 CR3 value to fail.
5. Abuse the vulnerable error handling path where nested_svm_vmexit() failure is ignored by callers.
6. Cause the affected virtual CPU, guest, or virtualization stack to crash, hang, or enter an inconsistent state, resulting in denial of service.

How to detect it

Look for evidence of local users or guest workloads exercising nested KVM on AMD hosts followed by VM instability, vCPU resets, triple faults, kernel warnings, or unexplained guest termination. Useful sources include kernel logs from dmesg or journald, hypervisor management logs from libvirt or QEMU, audit logs for /dev/kvm access, process execution records showing qemu-system processes launched by untrusted users, and configuration state showing kvm_amd nested virtualization enabled. Focus detection on sequences where /dev/kvm access or QEMU/KVM startup is followed by nested virtualization errors, CR3/MMU-related warnings, VM exit errors, triple faults, guest shutdowns, or host kernel warnings. There are no public exploit-specific payload strings in the provided data, so detection should be behavior-based rather than signature-only.

• /dev/kvm
• kvm_amd
• nested=1
• /sys/module/kvm_amd/parameters/nested
• qemu-system-x86_64
• qemu-kvm
• libvirtd
• virtqemud
• nested_svm_vmexit
• KVM: nSVM
• triple fault
• VMEXIT
• VMRUN
• CR3
• emulation failure
• guest disabled perfctr wrmsr
• BUG:
• WARNING: CPU:

What your security team should do

• Prioritize patching KVM hosts that run AMD CPUs and allow nested virtualization, especially multi-tenant, CI, cloud, lab, or developer platforms where untrusted users can access /dev/kvm.
• Inventory systems with the kvm_amd module loaded and nested virtualization enabled; treat these as the primary exposure set.
• Restrict /dev/kvm access to trusted users and remove unnecessary users from virtualization-related groups such as kvm or libvirt.
• Disable nested virtualization on hosts that do not explicitly require it.
• Monitor kernel, hypervisor, and guest lifecycle logs for unexplained VM crashes, triple faults, KVM warnings, nested VM exit failures, and repeated guest resets.
• Because EPSS is very low, the CVE is not in KEV, and no mature exploit is reported, handle this as important availability hardening rather than an emergency internet-wide exploitation event unless nested virtualization is exposed to untrusted parties.
• Ensure reboot orchestration is included in remediation plans, because kernel fixes are not effective until the patched kernel is running.