[BUG] KVM: x86: Hyper-V VP-assist page reuses the KVM PV-EOI gfn_to_hva_cache, so enabling both WARNs and fails KVM_RUN

[BUG] KVM: x86: Hyper-V VP-assist page reuses the KVM PV-EOI gfn_to_hva_cache, so enabling both WARNs and fails KVM_RUN

[Amirmohammad Eftekhar]

Hi,

Reporting a guest self-DoS (correctness/robustness; not memory-safety, not
guest->host).

The Hyper-V VP-assist page and KVM's PV-EOI feature share a single
gfn_to_hva_cache, vcpu->arch.pv_eoi.data:

 - Writing HV_X64_MSR_VP_ASSIST_PAGE arms the cache for the VP-assist page via
   kvm_lapic_set_pv_eoi(vcpu, gfn_to_gpa(gfn) | KVM_MSR_ENABLED,
   sizeof(struct hv_vp_assist_page))   /* hyperv.c ~1600 */
 - kvm_hv_get_assist_page() then reads it back with that same cache and the
   VP-assist length:
   kvm_read_guest_cached(kvm, &vcpu->arch.pv_eoi.data,
                         &hv_vcpu->vp_assist_page,
                         sizeof(struct hv_vp_assist_page))  /* hyperv.c ~952 */

pv_eoi.data is the one gfn_to_hva_cache shared between the two features. A guest
that has VP-assist enabled and then writes MSR_KVM_PV_EOI_EN (a different GPA,
len 1) re-initializes pv_eoi.data for the 1-byte PV-EOI object while VP-assist
stays enabled. The next kvm_hv_get_assist_page() then does a cached read of
sizeof(struct hv_vp_assist_page) against a cache set up for len 1 -> the
length/GPA mismatch trips the cache and KVM fails the read, surfacing as a WARN
and a failed KVM_RUN for a guest that did nothing architecturally illegal (the
two features are independent and both legitimately enableable).

Impact / class
--------------
Guest self-DoS (the guest breaks its own vCPU); low severity, no host memory
safety or cross-VM effect. Reported because "enable two unrelated, individually
valid features -> WARN + failed KVM_RUN" is a robustness bug.

Suggested direction
-------------------
Give the Hyper-V VP-assist page its own gfn_to_hva_cache instead of borrowing
vcpu->arch.pv_eoi.data, so the two features cannot clobber each other's cache.
Happy to send a patch once you confirm that's the preferred fix.

Read-confirmed against kvm-x86/next (tip of 2026-10-13); present in mainline
v7.3-rc6.

Thanks,
Amirmohammad

Re: [BUG] KVM: x86: Hyper-V VP-assist page reuses the KVM PV-EOI gfn_to_hva_cache, so enabling both WARNs and fails KVM_RUN

[Sean Christopherson]

On Sat, Oct 17, 2026, Amirmohammad Eftekhar wrote:
> Hi,
> 
> Reporting a guest self-DoS (correctness/robustness; not memory-safety, not
> guest->host).

And a KVM WARN, that's the only reason I care about "fixing" this.

> The Hyper-V VP-assist page and KVM's PV-EOI feature share a single
> gfn_to_hva_cache, vcpu->arch.pv_eoi.data:

I'm still flabbergasted that this is the case (I recently learned about this thanks
to another AI-found bug).

>  - Writing HV_X64_MSR_VP_ASSIST_PAGE arms the cache for the VP-assist page via
>    kvm_lapic_set_pv_eoi(vcpu, gfn_to_gpa(gfn) | KVM_MSR_ENABLED,
>    sizeof(struct hv_vp_assist_page))   /* hyperv.c ~1600 */
>  - kvm_hv_get_assist_page() then reads it back with that same cache and the
>    VP-assist length:
>    kvm_read_guest_cached(kvm, &vcpu->arch.pv_eoi.data,
>                          &hv_vcpu->vp_assist_page,
>                          sizeof(struct hv_vp_assist_page))  /* hyperv.c ~952 */
> 
> pv_eoi.data is the one gfn_to_hva_cache shared between the two features. A guest
> that has VP-assist enabled and then writes MSR_KVM_PV_EOI_EN (a different GPA,
> len 1) re-initializes pv_eoi.data for the 1-byte PV-EOI object while VP-assist
> stays enabled. The next kvm_hv_get_assist_page() then does a cached read of
> sizeof(struct hv_vp_assist_page) against a cache set up for len 1 -> the
> length/GPA mismatch trips the cache and KVM fails the read, surfacing as a WARN
> and a failed KVM_RUN for a guest that did nothing architecturally illegal (the
> two features are independent and both legitimately enableable).

Eh, given that no one has ever complained, and that enabling both at different
locations would probably break the guest anyways, I don't see any reason to go
out of our way to make this work.  If someone wants to clean up the Hyper-V mess,
they're more than welcome to, but for an immediate fix, I just want to prevent
KVM from tripping the WARN.

So as a stopgap (which will probably become the long-term behavior...), this?

diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
index c18f45f66c24..88cc5a6ce170 100644
--- a/arch/x86/kvm/hyperv.c
+++ b/arch/x86/kvm/hyperv.c
@@ -947,6 +947,15 @@ int kvm_hv_get_assist_page(struct kvm_vcpu *vcpu)
 	if (!hv_vcpu || !kvm_hv_assist_page_enabled(vcpu))
 		return -EFAULT;
 
+	/*
+	 * KVM reuses its own PV EOI feature to emulate Hyper-V's EOI Assist,
+	 * and rather stupidly reuses the same MSR and cache storage.  Treat
+	 * the assist page as inaccessible if the shared state is configured
+	 * only for PV EOI's single byte of data.
+	 */
+	if (vcpu->arch.pv_eoi.data.len < sizeof(struct hv_vp_assist_page))
+		return -EFAULT;
+
 	return kvm_read_guest_cached(vcpu->kvm, &vcpu->arch.pv_eoi.data,
 				     &hv_vcpu->vp_assist_page, sizeof(struct hv_vp_assist_page));
 }

Re: [BUG] KVM: x86: Hyper-V VP-assist page reuses the KVM PV-EOI gfn_to_hva_cache, so enabling both WARNs and fails KVM_RUN

[Amirmohammad Eftekhar]

Agreed, the stopgap looks right. Gating kvm_hv_get_assist_page() on
vcpu->arch.pv_eoi.data.len >= sizeof(struct hv_vp_assist_page) avoids the WARN
cleanly: when the shared cache is set up for PV EOI's single byte, the
VP-assist read is treated as inaccessible, with no need to untangle the shared
pv_eoi.data storage. And I agree making both features work at different GPAs
isn't worth chasing.

Would you like me to send this as a formal patch, with your Suggested-by,
tested against the reproducer (both features enabled at different GPAs,
confirming the WARN is gone and a well-formed VP-assist still reads back)?

Thanks,
Amirmohammad