CVE-2026-46076: Linux Kernel KVM Privilege Escalation Flaw

CVE-2026-46076 Overview

CVE-2026-46076 affects the Linux kernel's KVM nested SVM (nSVM) implementation. The flaw involves improper handling of VMMCALL instructions when an L2 guest is active and L1 does not intercept the hypercall. Under specific conditions involving nested_svm_l2_tlb_flush_enabled() returning true and unsupported Hyper-V hypercalls, KVM intercepts VMMCALL but fails to forward it to L1. This allows an L2 guest to issue hypercalls as if it were L1, deviating from architectural behavior that requires #UD (invalid opcode) when VMMCALL is not intercepted.

Critical Impact
A nested L2 virtual machine guest can invoke hypercalls intended for L1, breaking the nested virtualization isolation model on AMD SVM hosts.

Affected Products

Linux kernel with KVM nested SVM (AMD virtualization) support
Systems running nested virtualization on AMD hardware
Hyper-V-enlightened nested guest configurations

Discovery Timeline

2026-05-27 - CVE-2026-46076 published to NVD
2026-05-27 - Last updated in NVD database

Technical Details for CVE-2026-46076

Vulnerability Analysis

The vulnerability resides in the KVM nested SVM hypercall handling logic. When a Level 2 (L2) guest executes the VMMCALL instruction, KVM normally forwards the hypercall to the Level 1 (L1) hypervisor for processing. However, when nested_svm_l2_tlb_flush_enabled() returns true and L1 has not configured VMMCALL interception, KVM still intercepts the instruction. If the hypercall is not one of the supported Hyper-V hypercalls, KVM previously failed to either forward it to L1 or synthesize an architectural fault.

This behavioral gap let L2 guests execute hypercalls outside of L1's awareness. The fix explicitly synthesizes a #UD exception for unsupported VMMCALL invocations under these conditions, aligning KVM with the AMD architectural specification.

Root Cause

The root cause is incomplete state handling in KVM's nested SVM hypercall dispatch path. The Hyper-V TLFS does not document the behavior when L1 declines interception, an unsupported hypercall is issued, and nested_svm_l2_tlb_flush_enabled() is true. KVM defaulted to silently consuming the hypercall instead of returning control to L1 or raising #UD, breaking the architectural contract for VMMCALL.

Attack Vector

Exploitation requires a malicious or compromised L2 guest running under a nested hypervisor on AMD SVM hardware. The attacker executes VMMCALL with arguments that do not match supported Hyper-V hypercalls. With L1 not intercepting VMMCALL and TLB flush enlightenment enabled, KVM silently handles the instruction without notifying L1. The attacker gains the ability to trigger KVM-level hypercall handling intended only for L1, undermining nested isolation guarantees.

No verified public proof-of-concept code is available. Refer to the upstream kernel commits for the patch logic: Kernel commit 009c0f72, commit 5fb4a5f3, commit 924d721f, and commit c36991c6.

Detection Methods for CVE-2026-46076

Indicators of Compromise

Unexpected VMMCALL traces in KVM debug logs from L2 guests on AMD SVM hosts
Anomalous hypercall patterns from nested guests that do not match documented Hyper-V hypercall numbers
Nested virtualization workloads where L2 guests exhibit behavior consistent with direct hypervisor interaction

Detection Strategies

Audit running Linux kernel versions on AMD virtualization hosts to identify unpatched nested SVM configurations
Enable KVM tracepoints (kvm:kvm_hypercall, kvm:kvm_nested_vmexit) to log hypercall activity from nested guests
Correlate guest hypercall telemetry with L1 hypervisor logs to identify hypercalls not forwarded to L1

Monitoring Recommendations

Monitor dmesg and KVM audit logs on hypervisor hosts for unexpected #UD exceptions after patching
Track kernel package versions across virtualization fleets to confirm patch propagation
Alert on nested virtualization configurations running outdated kernels via configuration management tooling

How to Mitigate CVE-2026-46076

Immediate Actions Required

Apply the upstream Linux kernel patch series referenced in the kernel.org commits as soon as distribution updates become available
Inventory all AMD-based hosts running nested virtualization with KVM and prioritize patching
Restrict the ability to run untrusted L2 guest workloads on unpatched hosts

Patch Information

The fix synthesizes a #UD exception for VMMCALL when L2 is active, L1 does not intercept the hypercall, nested_svm_l2_tlb_flush_enabled() returns true, and the hypercall is not a supported Hyper-V hypercall. The patches are tagged for stable kernel backports. See the referenced kernel commits for the authoritative fix. Apply vendor-supplied kernel updates from your Linux distribution.

Workarounds

Disable nested virtualization on AMD SVM hosts where it is not required by setting the kvm-amd module parameter nested=0
Avoid running untrusted L2 guests until kernel updates are deployed
Where feasible, disable Hyper-V enlightenments in nested guest configurations to avoid triggering the vulnerable code path

bash

# Disable nested virtualization on AMD KVM hosts as a temporary workaround
sudo modprobe -r kvm_amd
echo "options kvm_amd nested=0" | sudo tee /etc/modprobe.d/kvm-amd-nested.conf
sudo modprobe kvm_amd

# Verify nested virtualization is disabled
cat /sys/module/kvm_amd/parameters/nested