[PATCH] KVM: arm64: Validate the SVE vector length in pkvm_vcpu_init_sve()

[PATCH] KVM: arm64: Validate the SVE vector length in pkvm_vcpu_init_sve()

[Fuad Tabba]

pkvm_vcpu_init_sve() clamps only the upper bound of the host-provided
sve_max_vl, so an invalid vector length reaches sve_state_size_from_vl()
and the WARN_ON() there, which is fatal at EL2. The existing
!sve_state_size test rejects such a length, but only after the macro has
run.

Check sve_vl_valid() before deriving the state size. A valid length
cannot yield a zero size, so the !sve_state_size test goes with it.

Fixes: 5db1bef93342 ("KVM: arm64: Track SVE state in the hypervisor vcpu structure")
Reported-by: Stefan Teodorescu <fane@google.com>
Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
---

Notes:
    Based on v7.2. Applies cleanly to kvmarm/next as well:
    pkvm_vcpu_init_sve() is identical on both.

 arch/arm64/kvm/hyp/nvhe/pkvm.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kvm/hyp/nvhe/pkvm.c b/arch/arm64/kvm/hyp/nvhe/pkvm.c
index 24d6f164129ac..095ebfce91b08 100644
--- a/arch/arm64/kvm/hyp/nvhe/pkvm.c
+++ b/arch/arm64/kvm/hyp/nvhe/pkvm.c
@@ -460,14 +460,15 @@ static int pkvm_vcpu_init_sve(struct pkvm_hyp_vcpu *hyp_vcpu, struct kvm_vcpu *h
 
 	/* Limit guest vector length to the maximum supported by the host. */
 	sve_max_vl = min(READ_ONCE(host_vcpu->arch.sve_max_vl), kvm_host_sve_max_vl);
-	sve_state_size = sve_state_size_from_vl(sve_max_vl);
 	sve_state = kern_hyp_va(READ_ONCE(host_vcpu->arch.sve_state));
 
-	if (!sve_state || !sve_state_size) {
+	if (!sve_vl_valid(sve_max_vl) || !sve_state) {
 		ret = -EINVAL;
 		goto err;
 	}
 
+	sve_state_size = sve_state_size_from_vl(sve_max_vl);
+
 	ret = hyp_pin_shared_mem(sve_state, sve_state + sve_state_size);
 	if (ret)
 		goto err;
-- 
2.39.5

Re: [PATCH] KVM: arm64: Validate the SVE vector length in pkvm_vcpu_init_sve()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] A fallible memory allocation failure inside `hyp_pin_shared_mem()` triggers a `WARN_ON()`, which results in a fatal hypervisor panic.
--

--- Patch [1]: [PATCH] KVM: arm64: Validate the SVE vector length in pkvm_vcpu_init_sve() ---
commit f011c5300d433db59b3f2b97e822b9e148c39b84
Author: Fuad Tabba <fuad.tabba@linux.dev>
KVM: arm64: Validate the SVE vector length in pkvm_vcpu_init_sve()

This commit updates pkvm_vcpu_init_sve() to validate the host-provided
SVE vector length before deriving its state size. This prevents an invalid
length from reaching the sve_state_size_from_vl() macro and triggering a
fatal EL2 WARN_ON().

> diff --git a/arch/arm64/kvm/hyp/nvhe/pkvm.c b/arch/arm64/kvm/hyp/nvhe/pkvm.c
> --- a/arch/arm64/kvm/hyp/nvhe/pkvm.c
> +++ b/arch/arm64/kvm/hyp/nvhe/pkvm.c
[ ... ]
> @@ -460,14 +460,15 @@ static int pkvm_vcpu_init_sve(struct pkvm_hyp_vcpu *hyp_vcpu, struct kvm_vcpu *h
[ ... ]
> +	sve_state_size = sve_state_size_from_vl(sve_max_vl);
> +
>  	ret = hyp_pin_shared_mem(sve_state, sve_state + sve_state_size);

[Severity: Critical]
This is a pre-existing issue, but looking at hyp_pin_shared_mem(), could a
memory allocation failure here trigger a fatal hypervisor panic?

If host userspace repeatedly creates VMs and vCPUs to exhaust the
hypervisor's memory pool, pkvm_create_mappings_locked() can return
-ENOMEM. 

Because hyp_pin_shared_mem() wraps this fallible call in a WARN_ON():

arch/arm64/kvm/hyp/nvhe/mem_protect.c:hyp_pin_shared_mem() {
    ...
    for (cur = start; cur < end; cur += PAGE_SIZE) {
        p = hyp_virt_to_page(cur);
        hyp_page_ref_inc(p);
        if (p->refcount == 1)
            WARN_ON(pkvm_create_mappings_locked((void *)cur,
                                                (void *)cur + PAGE_SIZE,
                                                PAGE_HYP));
    }
    ...
}

And since WARN_ON() is fatal at EL2, does this allow unprivileged host
userspace to intentionally crash the host system if the allocation fails?

>  	if (ret)
>  		goto err;
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260818093117.2379344-1-fuad.tabba@linux.dev?part=1

Re: [PATCH] KVM: arm64: Validate the SVE vector length in pkvm_vcpu_init_sve()

[Fuad Tabba]

On Tue, 18 Aug 2026 at 10:43, <sashiko-bot@kernel.org> wrote:
>
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>
> Pre-existing issues:
> - [Critical] A fallible memory allocation failure inside `hyp_pin_shared_mem()` triggers a `WARN_ON()`, which results in a fatal hypervisor panic.

It can't fail. hyp_s1_pgtable_pages() provisions the hyp stage-1 page
tables at init to cover all of memory at page granularity, so hpool
can always map any host page into the hyp linear map.

/fuad

> --
>
> --- Patch [1]: [PATCH] KVM: arm64: Validate the SVE vector length in pkvm_vcpu_init_sve() ---
> commit f011c5300d433db59b3f2b97e822b9e148c39b84
> Author: Fuad Tabba <fuad.tabba@linux.dev>
> KVM: arm64: Validate the SVE vector length in pkvm_vcpu_init_sve()
>
> This commit updates pkvm_vcpu_init_sve() to validate the host-provided
> SVE vector length before deriving its state size. This prevents an invalid
> length from reaching the sve_state_size_from_vl() macro and triggering a
> fatal EL2 WARN_ON().
>
> > diff --git a/arch/arm64/kvm/hyp/nvhe/pkvm.c b/arch/arm64/kvm/hyp/nvhe/pkvm.c
> > --- a/arch/arm64/kvm/hyp/nvhe/pkvm.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/pkvm.c
> [ ... ]
> > @@ -460,14 +460,15 @@ static int pkvm_vcpu_init_sve(struct pkvm_hyp_vcpu *hyp_vcpu, struct kvm_vcpu *h
> [ ... ]
> > +     sve_state_size = sve_state_size_from_vl(sve_max_vl);
> > +
> >       ret = hyp_pin_shared_mem(sve_state, sve_state + sve_state_size);
>
> [Severity: Critical]
> This is a pre-existing issue, but looking at hyp_pin_shared_mem(), could a
> memory allocation failure here trigger a fatal hypervisor panic?
>
> If host userspace repeatedly creates VMs and vCPUs to exhaust the
> hypervisor's memory pool, pkvm_create_mappings_locked() can return
> -ENOMEM.
>
> Because hyp_pin_shared_mem() wraps this fallible call in a WARN_ON():
>
> arch/arm64/kvm/hyp/nvhe/mem_protect.c:hyp_pin_shared_mem() {
>     ...
>     for (cur = start; cur < end; cur += PAGE_SIZE) {
>         p = hyp_virt_to_page(cur);
>         hyp_page_ref_inc(p);
>         if (p->refcount == 1)
>             WARN_ON(pkvm_create_mappings_locked((void *)cur,
>                                                 (void *)cur + PAGE_SIZE,
>                                                 PAGE_HYP));
>     }
>     ...
> }
>
> And since WARN_ON() is fatal at EL2, does this allow unprivileged host
> userspace to intentionally crash the host system if the allocation fails?
>
> >       if (ret)
> >               goto err;
> >
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260818093117.2379344-1-fuad.tabba@linux.dev?part=1

Re: [PATCH] KVM: arm64: Validate the SVE vector length in pkvm_vcpu_init_sve()

[Marc Zyngier]

On Tue, 18 Aug 2026 10:31:17 +0100,
Fuad Tabba <fuad.tabba@linux.dev> wrote:
> 
> pkvm_vcpu_init_sve() clamps only the upper bound of the host-provided
> sve_max_vl, so an invalid vector length reaches sve_state_size_from_vl()
> and the WARN_ON() there, which is fatal at EL2. The existing
> !sve_state_size test rejects such a length, but only after the macro has
> run.
> 
> Check sve_vl_valid() before deriving the state size. A valid length
> cannot yield a zero size, so the !sve_state_size test goes with it.
> 
> Fixes: 5db1bef93342 ("KVM: arm64: Track SVE state in the hypervisor vcpu structure")
> Reported-by: Stefan Teodorescu <fane@google.com>
> Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>

Reviewed-by: Marc Zyngier <maz@kernel.org>

	M.

-- 
Without deviation from the norm, progress is not possible.