CVE-2026-46076

What it actually does

This is a Linux KVM nested-virtualization flaw in the AMD SVM path. Under a specific nested guest configuration, an L2 guest can execute a VMMCALL that KVM intercepts but does not correctly forward to the L1 hypervisor and does not reject with the architecturally expected invalid-opcode exception. The result is that the L2 guest may be allowed to invoke hypercall behavior as if it were the L1 guest, weakening nested-virtualization isolation. The practical impact is local, guest-originated privilege-boundary bypass within KVM nested virtualization, with potential confidentiality and integrity impact and a stronger availability impact if malformed or unexpected hypercall handling destabilizes the VM or host virtualization stack.

Why it matters to the business

Organizations running Linux KVM with nested virtualization, particularly on AMD SVM-capable systems, may have a guest isolation risk where code running in a nested guest can interact with hypervisor functionality it should not be able to reach. This is most relevant to virtualization platforms, CI/CD systems that run nested hypervisors, cloud lab environments, malware sandboxes, hosting providers, and developer platforms that expose nested virtualization to untrusted or semi-trusted workloads. The vulnerability is not listed in CISA KEV, has very low EPSS, and has no indicated public exploit maturity, so broad opportunistic exploitation is not currently expected; however, the impact can be significant in environments that rely on nested virtualization as a security boundary.

How an attack unfolds

An attacker first needs code execution with low privileges inside a nested L2 guest running on a vulnerable Linux KVM host using AMD SVM nested virtualization. The L1 guest must not be configured to intercept the relevant VMMCALL, and the vulnerable KVM nested SVM TLB-flush-related path must be reachable. The attacker then executes a crafted or unsupported VMMCALL from the L2 guest. Instead of injecting an invalid-opcode exception into L2 or correctly forwarding the event to L1, vulnerable KVM handling can process the call in a context that effectively treats L2 as if it were L1. Depending on the reachable hypercall behavior and configuration, this can allow unauthorized interaction with virtualization internals, disruption of nested guest execution, or other violations of the intended L1/L2 isolation model.

How to fix it

Update the Linux kernel to a version that includes the KVM nSVM fix for unhandled VMMCALL handling. Because no exact fixed version was provided, use the security advisory and kernel package from the relevant Linux distribution or upstream stable kernel branch and confirm that the patch behavior is present: unhandled VMMCALL from L2 should receive #UD when L1 does not intercept it, except for explicitly supported Hyper-V hypercalls. If immediate patching is not possible, reduce exposure by disabling nested virtualization where it is not required, avoiding untrusted workloads in nested-virtualization environments, restricting access to systems that expose KVM nested virtualization, and prioritizing updates on AMD SVM hosts that allow tenants, developers, CI jobs, sandboxes, or labs to run nested hypervisors.

How to confirm the fix worked

Confirm the running kernel package is updated to a vendor release containing the KVM nSVM VMMCALL fix. On affected hosts, verify whether AMD KVM nested virtualization is enabled by checking the kvm_amd nested module parameter and virtualization host configuration. If source validation is used, confirm the kernel includes logic that explicitly synthesizes #UD for unhandled L2 VMMCALLs when L1 did not request interception and the call is not a supported Hyper-V hypercall. In a non-production test environment, run a controlled nested-virtualization test where an L2 guest issues an unsupported VMMCALL and confirm the guest receives an invalid-opcode exception rather than successful hypercall handling or host instability. After mitigation by configuration, confirm nested virtualization is disabled or unavailable to untrusted workloads.

Typical attack path

1. Gain the ability to run code inside an L2 nested guest on a Linux KVM system using AMD SVM nested virtualization.
2. Confirm that nested virtualization is enabled and that the workload is running under a vulnerable KVM kernel.
3. Trigger the vulnerable nested SVM path by executing VMMCALL from the L2 guest under conditions where L1 does not intercept the call.
4. Use an unsupported or unexpected hypercall value to reach the flawed handling path.
5. Cause KVM to process the call incorrectly instead of injecting #UD into L2 or forwarding it to L1.
6. Leverage the resulting nested-virtualization boundary violation for unauthorized hypervisor interaction, guest disruption, or further exploitation.

How to detect it

There are no reliable public indicators that uniquely prove exploitation of this flaw, and the vulnerable VMMCALL path is not normally logged by default. Detection should focus on exposure assessment and suspicious nested-virtualization behavior. Review virtualization host inventories for Linux KVM on AMD systems with nested virtualization enabled, especially where untrusted L2 guests are allowed. Examine kernel logs, hypervisor logs, and monitoring telemetry for unexplained KVM warnings, nested guest crashes, repeated invalid-opcode or hypercall-related faults, sudden VM resets, host CPU spikes tied to nested guests, or availability events after unusual activity inside L2 guests. Where feasible, enable or review KVM tracepoints, eBPF telemetry, or hypervisor instrumentation for unexpected VMMCALL activity from nested guests. Incident responders should preserve host kernel logs, guest console logs, hypervisor management events, and memory/CPU telemetry around any unexplained nested-virtualization instability. Absence of logs does not rule out exploitation because successful triggering may leave little or no durable artifact.

What your security team should do

• Inventory Linux KVM hosts that run AMD SVM and determine where nested virtualization is enabled.
• Prioritize patching virtualization hosts that run untrusted, multi-tenant, developer, CI/CD, sandbox, or lab workloads with nested virtualization enabled.
• If patching is delayed, disable nested virtualization on kvm_amd where operationally feasible or restrict it to trusted workloads only.
• Review whether nested virtualization is being treated as a security boundary; if so, increase isolation for L2 workloads until patched.
• Monitor vendor kernel advisories for exact fixed kernel package versions and deploy the appropriate distribution-provided update rather than relying only on upstream version comparisons.
• Because no KEV listing, ransomware use, or public exploit maturity is indicated, handle as a targeted/local virtualization escape-risk issue rather than an internet-scale emergency, but do not defer on exposed virtualization platforms.