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

https://bugzilla.kernel.org/show_bug.cgi?id=221841

--- Comment #1 from Sean Christopherson ([email protected]) ---
+Vitaly

On Thu, Aug 06, 2026, [email protected] 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: [email protected]
>           Reporter: [email protected]
>         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);

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.