Re: [Bug 221841] New: KVM: nested VMX eVMCS VMPTRLD/VMPTRST causes infinite VM-Exit loop due to missing RIP advance

[Sean Christopherson <seanjc@google.com>]

+Vitaly

On Thu, Aug 06, 2026, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=221841
> 
>             Bug ID: 221841
>            Summary: KVM: nested VMX eVMCS VMPTRLD/VMPTRST causes infinite
>                     VM-Exit loop due to missing RIP advance
>            Product: Virtualization
>            Version: unspecified
>           Hardware: All
>                 OS: Linux
>             Status: NEW
>           Severity: high
>           Priority: P3
>          Component: kvm
>           Assignee: virtualization_kvm@kernel-bugs.osdl.org
>           Reporter: f734222792@gmail.com
>         Regression: No
> 
> Created attachment 310582
>   --> https://bugzilla.kernel.org/attachment.cgi?id=310582&action=edit
> Proof-of-concept exploit demonstrating infinite VM-Exit loop caused by missing
> RIP advancement in KVM nested VMX eVMCS VMPTRLD handler.
> 
> When eVMCS (enlightened VMCS, Hyper-V enlightened VMCS) is enabled, 
> the nested VMX handlers for VMPTRLD and VMPTRST return directly without 
> advancing the guest instruction pointer (RIP).
> 
> Affected code paths:
> 
> arch/x86/kvm/vmx/nested.c
> 
> handle_vmptrld():
>     if (evmcs)
>         return 1;
> 
> handle_vmptrst():
>     if (evmcs)
>         return 1;
> 
> 
> Unlike other VMX instruction handlers, these paths do not call:
> 
> - kvm_skip_emulated_instruction()
> - nested_vmx_succeed()
> - nested_vmx_fail()
> - nested_vmx_failInvalid()
> 
> Therefore, the L1 guest RIP remains unchanged after VM-Exit handling.
> 
> Reproduction logic:
> 
> 1. Enable nested VMX with Hyper-V enlightened VMCS (eVMCS).
> 2. Run an L1 guest.
> 3. Execute VMPTRLD or VMPTRST instruction inside L1 guest.
> 
> Execution flow:
> 
> L1 guest executes VMPTRLD
>         |
>         v
> VM-Exit to L0 KVM
>         |
>         v
> handle_vmptrld()
>         |
>         v
> if (evmcs)
>         return 1;
>         |
>         v
> No RIP advance
>         |
>         v
> VM-Entry resumes L1 guest
>         |
>         v
> Same VMPTRLD instruction executes again
> 
> This creates an infinite VM-Exit loop.
> 
> Impact:
> 
> A malicious L1 guest can continuously trigger VM-Exit handling and consume
> host CPU resources, resulting in denial of service.

No, it doesn't.  There are no "host CPU" vs. "guest CPU" resources, it's all just
physical CPU resources.  Whether the CPU is running guest code or host code is
irrelevant.  What matters is that KVM honors NEED_RESCHED (especially on
non-preemptible kernels, i.e. before PREEMPT_LAZY came along), which it very much
does in the slow path VM-Entry/VM-Exit loop.

> The issue affects availability only.

Only the availibility of the L1 hypervisor.

> Technical analysis:
> 
> The eVMCS path should behave similarly to other unsupported nested VMX
> instructions.

Only if the TLFS allows it.  I assume it just says "unsupported" or "undefined
behavior", i.e. KVM can probably do whatever it wants.  Vitaly?

> Replace the direct return:
> 
>     if (evmcs)
>         return 1;
> 
> with an error handling path that advances RIP, for example:
> 
>     if (evmcs)
>         return nested_vmx_fail(vcpu,
>             VMXERR_VMPTRLD_VMPTRST_WITH_EVMCS_NOT_SUPPORTED);

VMXERR_VMPTRLD_INCORRECT_VMCS_REVISION_ID is probably the best fit?

> or at minimum explicitly call:
> 
>     kvm_skip_emulated_instruction(vcpu);