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

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

[bugzilla-daemon]

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.

The issue affects availability only.




Technical analysis:

The eVMCS path should behave similarly to other unsupported nested VMX
instructions.

For example, handle_vmread() correctly handles eVMCS:

    if (evmcs)
        return nested_vmx_failInvalid(vcpu);

which advances RIP through the normal VMX failure handling path.

However, handle_vmptrld() and handle_vmptrst() only return 1 without
instruction advancement.


Suggested fix:

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);

or at minimum explicitly call:

    kvm_skip_emulated_instruction(vcpu);


Verification:

Confirmed:

1. eVMCS VMPTRLD/VMPTRST paths contain direct return 1.
2. No RIP advancement occurs.
3. vmx_handle_exit does not automatically advance RIP.
4. VMX instructions executed in non-root mode always cause VM-Exit.
5. The issue reproduces as an endless VM-Exit loop under eVMCS.


Workaround:

Disable Hyper-V enlightened VMCS / eVMCS support.

No known CVE assigned.

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

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

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

[Sean Christopherson]

+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);

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

[bugzilla-daemon]

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

--- Comment #1 from 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);

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

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

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

[bugzilla-daemon]

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

vkuznets@redhat.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vkuznets@redhat.com

--- Comment #2 from vkuznets@redhat.com ---
(In reply to Sean Christopherson from comment #1)

> > 
> > 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.

Yes, basically, misbehaving L1 hypervisor can shoot itself in the foot.

> 
> > 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?

VMREAD/VMWRITE with eVMCS are explicitly called 'unsupported' in the TLFS:

"Any VMREAD or VMWRITE instructions while an enlightened VMCS is active is
unsupported and can result in unexpected behavior.". 

As for VMPTRLD, we only have
"No VMPTRLD instruction must be executed to make an enlightened VMCS active or
current." but there's nothing about the expected result there. VMPTRST is not
mentioned. 

So I guess we can do whatever we want in KVM and skipping the instruction is
not a bad thing. Ideally, we can try and see what genuine Hyper-V gives us in
this situation (by e.g. running an instrumented version of KVM there). It does
not seem that we have an extreme urgency here so I can put it to my backlog and
try to get to it some time next week -- unless someone beats me to it of
course!

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

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

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

[Sean Christopherson]

On Fri, Aug 07, 2026, bugzilla-daemon@kernel.org wrote:
> > > 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?
> 
> VMREAD/VMWRITE with eVMCS are explicitly called 'unsupported' in the TLFS:
> 
> "Any VMREAD or VMWRITE instructions while an enlightened VMCS is active is
> unsupported and can result in unexpected behavior.". 
> 
> As for VMPTRLD, we only have
> "No VMPTRLD instruction must be executed to make an enlightened VMCS active or
> current." but there's nothing about the expected result there. VMPTRST is not
> mentioned. 
> 
> So I guess we can do whatever we want in KVM and skipping the instruction is
> not a bad thing. Ideally, we can try and see what genuine Hyper-V gives us in
> this situation (by e.g. running an instrumented version of KVM there).

Heh, I agree, so long as Hyper-V's behavior is to either signal VM-Fail or inject
an exception of some kind.  If Hyper-V loops (like KVM does) or skips the
instruction without synthesizing an error of some kind, then I think we should
diverge from Hyper-V, as not signalling failure of some kind is pretty gross.

If we diverge from Hyper-V, think my vote would be to inject #UD or #GP, because
for all intents and purposes VMPTR{LD,ST} become unsupported instructions.  E.g.

diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index 7ed79894d11d..e743c892eeb8 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -5888,6 +5888,12 @@ static int handle_vmptrld(struct kvm_vcpu *vcpu)
        if (!nested_vmx_check_permission(vcpu))
                return 1;
 
+       /* Forbid normal VMPTRLD if Enlightened version was used */
+       if (nested_vmx_is_evmptr12_valid(vmx)) {
+               kvm_queue_exception(vcpu, UD_VECTOR);
+               return 1;
+       }
+
        if (nested_vmx_get_vmptr(vcpu, &vmptr, &r))
                return r;
 
@@ -5897,10 +5903,6 @@ static int handle_vmptrld(struct kvm_vcpu *vcpu)
        if (vmptr == vmx->nested.vmxon_ptr)
                return nested_vmx_fail(vcpu, VMXERR_VMPTRLD_VMXON_POINTER);
 
-       /* Forbid normal VMPTRLD if Enlightened version was used */
-       if (nested_vmx_is_evmptr12_valid(vmx))
-               return 1;
-
        if (vmx->nested.current_vmptr != vmptr) {
                struct gfn_to_hva_cache *ghc = &vmx->nested.vmcs12_cache;
                struct vmcs_hdr hdr;
@@ -5961,8 +5963,10 @@ static int handle_vmptrst(struct kvm_vcpu *vcpu)
        if (!nested_vmx_check_permission(vcpu))
                return 1;
 
-       if (unlikely(nested_vmx_is_evmptr12_valid(to_vmx(vcpu))))
+       if (unlikely(nested_vmx_is_evmptr12_valid(to_vmx(vcpu)))) {
+               kvm_queue_exception(vcpu, UD_VECTOR);
                return 1;
+       }
 
        if (get_vmx_mem_address(vcpu, exit_qual, instr_info,
                                true, sizeof(gpa_t), &gva))

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

[bugzilla-daemon]

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

--- Comment #3 from Sean Christopherson (seanjc@google.com) ---
On Fri, Aug 07, 2026, bugzilla-daemon@kernel.org wrote:
> > > 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?
> 
> VMREAD/VMWRITE with eVMCS are explicitly called 'unsupported' in the TLFS:
> 
> "Any VMREAD or VMWRITE instructions while an enlightened VMCS is active is
> unsupported and can result in unexpected behavior.". 
> 
> As for VMPTRLD, we only have
> "No VMPTRLD instruction must be executed to make an enlightened VMCS active
> or
> current." but there's nothing about the expected result there. VMPTRST is not
> mentioned. 
> 
> So I guess we can do whatever we want in KVM and skipping the instruction is
> not a bad thing. Ideally, we can try and see what genuine Hyper-V gives us in
> this situation (by e.g. running an instrumented version of KVM there).

Heh, I agree, so long as Hyper-V's behavior is to either signal VM-Fail or
inject
an exception of some kind.  If Hyper-V loops (like KVM does) or skips the
instruction without synthesizing an error of some kind, then I think we should
diverge from Hyper-V, as not signalling failure of some kind is pretty gross.

If we diverge from Hyper-V, think my vote would be to inject #UD or #GP,
because
for all intents and purposes VMPTR{LD,ST} become unsupported instructions. 
E.g.

diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index 7ed79894d11d..e743c892eeb8 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -5888,6 +5888,12 @@ static int handle_vmptrld(struct kvm_vcpu *vcpu)
        if (!nested_vmx_check_permission(vcpu))
                return 1;

+       /* Forbid normal VMPTRLD if Enlightened version was used */
+       if (nested_vmx_is_evmptr12_valid(vmx)) {
+               kvm_queue_exception(vcpu, UD_VECTOR);
+               return 1;
+       }
+
        if (nested_vmx_get_vmptr(vcpu, &vmptr, &r))
                return r;

@@ -5897,10 +5903,6 @@ static int handle_vmptrld(struct kvm_vcpu *vcpu)
        if (vmptr == vmx->nested.vmxon_ptr)
                return nested_vmx_fail(vcpu, VMXERR_VMPTRLD_VMXON_POINTER);

-       /* Forbid normal VMPTRLD if Enlightened version was used */
-       if (nested_vmx_is_evmptr12_valid(vmx))
-               return 1;
-
        if (vmx->nested.current_vmptr != vmptr) {
                struct gfn_to_hva_cache *ghc = &vmx->nested.vmcs12_cache;
                struct vmcs_hdr hdr;
@@ -5961,8 +5963,10 @@ static int handle_vmptrst(struct kvm_vcpu *vcpu)
        if (!nested_vmx_check_permission(vcpu))
                return 1;

-       if (unlikely(nested_vmx_is_evmptr12_valid(to_vmx(vcpu))))
+       if (unlikely(nested_vmx_is_evmptr12_valid(to_vmx(vcpu)))) {
+               kvm_queue_exception(vcpu, UD_VECTOR);
                return 1;
+       }

        if (get_vmx_mem_address(vcpu, exit_qual, instr_info,
                                true, sizeof(gpa_t), &gva))

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

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