* Re: [Bug 221841] New: KVM: nested VMX eVMCS VMPTRLD/VMPTRST causes infinite VM-Exit loop due to missing RIP advance
2026-08-06 7:11 [Bug 221841] New: KVM: nested VMX eVMCS VMPTRLD/VMPTRST causes infinite VM-Exit loop due to missing RIP advance bugzilla-daemon
@ 2026-08-06 14:01 ` Sean Christopherson
2026-08-06 14:01 ` [Bug 221841] " bugzilla-daemon
` (2 subsequent siblings)
3 siblings, 0 replies; 6+ messages in thread
From: Sean Christopherson @ 2026-08-06 14:01 UTC (permalink / raw)
To: bugzilla-daemon; +Cc: kvm, Vitaly Kuznetsov
+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);
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug 221841] KVM: nested VMX eVMCS VMPTRLD/VMPTRST causes infinite VM-Exit loop due to missing RIP advance
2026-08-06 7:11 [Bug 221841] New: KVM: nested VMX eVMCS VMPTRLD/VMPTRST causes infinite VM-Exit loop due to missing RIP advance bugzilla-daemon
2026-08-06 14:01 ` Sean Christopherson
@ 2026-08-06 14:01 ` bugzilla-daemon
2026-08-07 9:17 ` bugzilla-daemon
2026-08-07 13:56 ` bugzilla-daemon
3 siblings, 0 replies; 6+ messages in thread
From: bugzilla-daemon @ 2026-08-06 14:01 UTC (permalink / raw)
To: kvm
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug 221841] KVM: nested VMX eVMCS VMPTRLD/VMPTRST causes infinite VM-Exit loop due to missing RIP advance
2026-08-06 7:11 [Bug 221841] New: KVM: nested VMX eVMCS VMPTRLD/VMPTRST causes infinite VM-Exit loop due to missing RIP advance bugzilla-daemon
2026-08-06 14:01 ` Sean Christopherson
2026-08-06 14:01 ` [Bug 221841] " bugzilla-daemon
@ 2026-08-07 9:17 ` bugzilla-daemon
2026-08-07 13:56 ` Sean Christopherson
2026-08-07 13:56 ` bugzilla-daemon
3 siblings, 1 reply; 6+ messages in thread
From: bugzilla-daemon @ 2026-08-07 9:17 UTC (permalink / raw)
To: kvm
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.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [Bug 221841] KVM: nested VMX eVMCS VMPTRLD/VMPTRST causes infinite VM-Exit loop due to missing RIP advance
2026-08-07 9:17 ` bugzilla-daemon
@ 2026-08-07 13:56 ` Sean Christopherson
0 siblings, 0 replies; 6+ messages in thread
From: Sean Christopherson @ 2026-08-07 13:56 UTC (permalink / raw)
To: bugzilla-daemon; +Cc: kvm
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))
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [Bug 221841] KVM: nested VMX eVMCS VMPTRLD/VMPTRST causes infinite VM-Exit loop due to missing RIP advance
2026-08-06 7:11 [Bug 221841] New: KVM: nested VMX eVMCS VMPTRLD/VMPTRST causes infinite VM-Exit loop due to missing RIP advance bugzilla-daemon
` (2 preceding siblings ...)
2026-08-07 9:17 ` bugzilla-daemon
@ 2026-08-07 13:56 ` bugzilla-daemon
3 siblings, 0 replies; 6+ messages in thread
From: bugzilla-daemon @ 2026-08-07 13:56 UTC (permalink / raw)
To: kvm
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.
^ permalink raw reply related [flat|nested] 6+ messages in thread