GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel KVM nSVM: L2 guest can issue hypercalls as if it were L1 when VMMCALL is not intercepted

CVSS 7.9CVE-2026-46076Kernel, userspace & hypervisorcurated

Impact

On AMD hosts, when L2 is active, L1 does not intercept VMMCALL and nested_svm_l2_tlb_flush_enabled() is true, KVM intercepts VMMCALL but never forwards it to L1 - so a nested guest can make hypercalls as though it were the L1 hypervisor instead of taking the architectural #UD. That is a confused-deputy path across a nesting boundary on exactly the hosts a GPU cloud uses to sell nested-capable AMD instances, and it breaks the isolation assumption the L1 hypervisor is written against. The fix explicitly synthesizes #UD for unsupported hypercalls in that state. The record does not demonstrate host escape or data disclosure; treat it as a nesting isolation break rather than a proven escape.

Who can reach it

Local: code running in a nested (L2) guest on an AMD host with nested SVM enabled. Requires the operator to have exposed nested virtualization to the tenant; no network path.

What to do

Apply the stable kernel fix for your branch (commits in the references) and reboot the hypervisor node, or reload kvm_amd with all VMs stopped. Until then, disabling nested virtualization (kvm_amd nested=0) for tenant VMs removes the condition entirely and is the cheaper interim step.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.