[PATCH 0/4] KVM: arm64: pKVM SVE vCPU init fixes

[PATCH 0/4] KVM: arm64: pKVM SVE vCPU init fixes

[Fuad Tabba]

Hi folks,

If it's not the GIC, it's SVE. I found these while preparing the
follow-up to the pKVM core series [1].

Patch 1 was posted on its own [2] and carries Marc's Reviewed-by. It is
unchanged and included here because it has not been picked up yet and
the rest of the series does not apply without it.

Patches 2 and 4 are two ways to reach the same broken state, a vCPU
whose sve_state is NULL while vcpu_has_sve() is true, so the world
switch loads the guest's SVE state from it. EL2 keeps two answers to
"does this guest have SVE": KVM_ARCH_FLAG_GUEST_HAS_SVE, which the
world switch reads, and KVM_ARM_VCPU_SVE, which pkvm_vcpu_init_sve()
reads. Patch 2 stops EL2 desynchronising them itself on an init
failure. Patch 4 stops the host handing them over already
desynchronised. Patch 3 keys the unpin on the state it unpins rather
than on the feature bit, which agree for any vCPU that completed init.

All of it needs a host that misreports its own vCPU state, so none of
it is reachable from host userspace.

Based on Linux 7.2, and applies cleanly to kvmarm/next.

Cheers,
/fuad

[1] https://lore.kernel.org/all/178552142335.30097.18179093757678605679.b4-ty@kernel.org/
[2] https://lore.kernel.org/all/20260818093117.2379344-1-fuad.tabba@linux.dev/

Fuad Tabba (4):
  KVM: arm64: Validate the SVE vector length in pkvm_vcpu_init_sve()
  KVM: arm64: Do not clear VM-wide SVE feature on vCPU init failure
  KVM: arm64: Key unpin_host_sve_state() on the state it unpins
  KVM: arm64: Derive GUEST_HAS_SVE from the SVE feature bit at EL2

 arch/arm64/kvm/hyp/nvhe/pkvm.c | 29 +++++++++++++----------------
 1 file changed, 13 insertions(+), 16 deletions(-)

-- 
2.39.5

[PATCH 1/4] 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>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
---
 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

[PATCH 2/4] KVM: arm64: Do not clear VM-wide SVE feature on vCPU init failure

[Fuad Tabba]

pkvm_vcpu_init_sve() clears KVM_ARM_VCPU_SVE in kvm->arch.vcpu_features
when it fails, but vcpu_has_sve() tests KVM_ARCH_FLAG_GUEST_HAS_SVE,
which is left set. Later vCPUs on that VM then skip the SVE setup and
register with a NULL sve_state, which the guest's first FP access hands
to sve_load_state().

Return the error without touching vcpu_features.

Fixes: 5db1bef93342 ("KVM: arm64: Track SVE state in the hypervisor vcpu structure")
Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
---
 arch/arm64/kvm/hyp/nvhe/pkvm.c | 13 ++++---------
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/kvm/hyp/nvhe/pkvm.c b/arch/arm64/kvm/hyp/nvhe/pkvm.c
index 095ebfce91b08..73e6ee059eebb 100644
--- a/arch/arm64/kvm/hyp/nvhe/pkvm.c
+++ b/arch/arm64/kvm/hyp/nvhe/pkvm.c
@@ -451,7 +451,7 @@ static int pkvm_vcpu_init_sve(struct pkvm_hyp_vcpu *hyp_vcpu, struct kvm_vcpu *h
 	unsigned int sve_max_vl;
 	size_t sve_state_size;
 	void *sve_state;
-	int ret = 0;
+	int ret;
 
 	if (!vcpu_has_feature(vcpu, KVM_ARM_VCPU_SVE)) {
 		vcpu_clear_flag(vcpu, VCPU_SVE_FINALIZED);
@@ -462,24 +462,19 @@ static int pkvm_vcpu_init_sve(struct pkvm_hyp_vcpu *hyp_vcpu, struct kvm_vcpu *h
 	sve_max_vl = min(READ_ONCE(host_vcpu->arch.sve_max_vl), kvm_host_sve_max_vl);
 	sve_state = kern_hyp_va(READ_ONCE(host_vcpu->arch.sve_state));
 
-	if (!sve_vl_valid(sve_max_vl) || !sve_state) {
-		ret = -EINVAL;
-		goto err;
-	}
+	if (!sve_vl_valid(sve_max_vl) || !sve_state)
+		return -EINVAL;
 
 	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;
+		return ret;
 
 	vcpu->arch.sve_state = sve_state;
 	vcpu->arch.sve_max_vl = sve_max_vl;
 
 	return 0;
-err:
-	clear_bit(KVM_ARM_VCPU_SVE, vcpu->kvm->arch.vcpu_features);
-	return ret;
 }
 
 static int vm_copy_id_regs(struct pkvm_hyp_vcpu *hyp_vcpu)
-- 
2.39.5

[PATCH 3/4] KVM: arm64: Key unpin_host_sve_state() on the state it unpins

[Fuad Tabba]

unpin_host_sve_state() gates on the VM's SVE feature bit, but what it
unpins is the state pkvm_vcpu_init_sve() pinned. A vCPU that completed
init has sve_state set exactly when that bit is set, so the two agree.
Gate on sve_state, which is what is being unpinned.

Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
---
 arch/arm64/kvm/hyp/nvhe/pkvm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kvm/hyp/nvhe/pkvm.c b/arch/arm64/kvm/hyp/nvhe/pkvm.c
index 73e6ee059eebb..1d8cc984fb88c 100644
--- a/arch/arm64/kvm/hyp/nvhe/pkvm.c
+++ b/arch/arm64/kvm/hyp/nvhe/pkvm.c
@@ -398,10 +398,10 @@ static void unpin_host_sve_state(struct pkvm_hyp_vcpu *hyp_vcpu)
 {
 	void *sve_state;
 
-	if (!vcpu_has_feature(&hyp_vcpu->vcpu, KVM_ARM_VCPU_SVE))
+	sve_state = hyp_vcpu->vcpu.arch.sve_state;
+	if (!sve_state)
 		return;
 
-	sve_state = hyp_vcpu->vcpu.arch.sve_state;
 	hyp_unpin_shared_mem(sve_state,
 			     sve_state + vcpu_sve_state_size(&hyp_vcpu->vcpu));
 }
-- 
2.39.5

[PATCH 4/4] KVM: arm64: Derive GUEST_HAS_SVE from the SVE feature bit at EL2

[Fuad Tabba]

pkvm_init_features_from_host() takes KVM_ARCH_FLAG_GUEST_HAS_SVE and
KVM_ARM_VCPU_SVE from the host separately, but pkvm_vcpu_init_sve()
tests the bit while vcpu_has_sve() reads the flag. A host that sets the
flag without the bit gets a vCPU with a NULL sve_state that the world
switch loads the guest's SVE state from.

Derive the flag from the bit, and drop the protected path's copy of the
host's flag, which is dead code since protected VMs are not allowed SVE.

Fixes: 41d6028e28bd ("KVM: arm64: Convert the SVE guest vcpu flag to a vm flag")
Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
---
 arch/arm64/kvm/hyp/nvhe/pkvm.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kvm/hyp/nvhe/pkvm.c b/arch/arm64/kvm/hyp/nvhe/pkvm.c
index 1d8cc984fb88c..6efca70e5f5a9 100644
--- a/arch/arm64/kvm/hyp/nvhe/pkvm.c
+++ b/arch/arm64/kvm/hyp/nvhe/pkvm.c
@@ -360,7 +360,7 @@ static void pkvm_init_features_from_host(struct pkvm_hyp_vm *hyp_vm, const struc
 		if (test_bit(KVM_ARCH_FLAG_WRITABLE_IMP_ID_REGS, &host_arch_flags))
 			hyp_vm->kvm.arch.midr_el1 = host_kvm->arch.midr_el1;
 
-		return;
+		goto out;
 	}
 
 	if (kvm_pkvm_ext_allowed(kvm, KVM_CAP_ARM_MTE))
@@ -379,13 +379,14 @@ static void pkvm_init_features_from_host(struct pkvm_hyp_vm *hyp_vm, const struc
 	if (kvm_pkvm_ext_allowed(kvm, KVM_CAP_ARM_PTRAUTH_GENERIC))
 		set_bit(KVM_ARM_VCPU_PTRAUTH_GENERIC, allowed_features);
 
-	if (kvm_pkvm_ext_allowed(kvm, KVM_CAP_ARM_SVE)) {
+	if (kvm_pkvm_ext_allowed(kvm, KVM_CAP_ARM_SVE))
 		set_bit(KVM_ARM_VCPU_SVE, allowed_features);
-		kvm->arch.flags |= host_arch_flags & BIT(KVM_ARCH_FLAG_GUEST_HAS_SVE);
-	}
 
 	bitmap_and(kvm->arch.vcpu_features, host_kvm->arch.vcpu_features,
 		   allowed_features, KVM_VCPU_MAX_FEATURES);
+out:
+	__assign_bit(KVM_ARCH_FLAG_GUEST_HAS_SVE, &kvm->arch.flags,
+		     kvm_vcpu_has_feature(kvm, KVM_ARM_VCPU_SVE));
 }
 
 static void unpin_host_vcpu(struct kvm_vcpu *host_vcpu)
-- 
2.39.5

Re: [PATCH 2/4] KVM: arm64: Do not clear VM-wide SVE feature on vCPU init failure

[sashiko-bot]

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

Pre-existing issues:
- [High] Hypervisor DoS via WARN_ON() upon page table allocation failure
--

--- Patch [2]: [PATCH 2/4] KVM: arm64: Do not clear VM-wide SVE feature on vCPU init failure ---
commit 1188c411e2a65143d7371d1038c2752c0f2de6c0
Author: Fuad Tabba <fuad.tabba@linux.dev>

KVM: arm64: Do not clear VM-wide SVE feature on vCPU init failure

pkvm_vcpu_init_sve() clears KVM_ARM_VCPU_SVE in kvm->arch.vcpu_features
when it fails, but vcpu_has_sve() tests KVM_ARCH_FLAG_GUEST_HAS_SVE,
which is left set. Later vCPUs on that VM then skip the SVE setup and
register with a NULL sve_state, which the guest's first FP access hands
to sve_load_state().

Return the error without touching vcpu_features.

> diff --git a/arch/arm64/kvm/hyp/nvhe/pkvm.c b/arch/arm64/kvm/hyp/nvhe/pkvm.c
> index c31b9d46b8b60..4340b13ee295b 100644
> --- a/arch/arm64/kvm/hyp/nvhe/pkvm.c
> +++ b/arch/arm64/kvm/hyp/nvhe/pkvm.c

[ ... ]

> @@ -462,24 +462,19 @@ static int pkvm_vcpu_init_sve(struct pkvm_hyp_vcpu *hyp_vcpu, struct kvm_vcpu *h
>  	sve_max_vl = min(READ_ONCE(host_vcpu->arch.sve_max_vl), kvm_host_sve_max_vl);
>  	sve_state = kern_hyp_va(READ_ONCE(host_vcpu->arch.sve_state));
>  
> -	if (!sve_vl_valid(sve_max_vl) || !sve_state) {
> -		ret = -EINVAL;
> -		goto err;
> -	}
> +	if (!sve_vl_valid(sve_max_vl) || !sve_state)
> +		return -EINVAL;
>  
>  	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;
> +		return ret;

[Severity: High]
This is a pre-existing issue, but can the call to hyp_pin_shared_mem()
trigger a hypervisor panic if EL2 memory is exhausted?

Looking at hyp_pin_shared_mem() in arch/arm64/kvm/hyp/nvhe/mem_protect.c,
it wraps the mapping allocation in a WARN_ON:

        if (p->refcount == 1)
                WARN_ON(pkvm_create_mappings_locked((void *)cur,
                                                    (void *)cur + PAGE_SIZE,
                                                    PAGE_HYP));

At EL2 under nVHE/pKVM, WARN_ON() expands to a BRK instruction which panics
the hypervisor and brings down the host.

Since host userspace can repeatedly invoke KVM ioctls to create VMs or vCPUs
and exhaust the bounded EL2 memory pool, pkvm_create_mappings_locked()
might eventually fail and return -ENOMEM.

Does this allow an unprivileged host process to hit the WARN_ON and crash
the host system?

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

Re: [PATCH 2/4] KVM: arm64: Do not clear VM-wide SVE feature on vCPU init failure

[Fuad Tabba]

On Tue, 25 Aug 2026 at 10:18, <sashiko-bot@kernel.org> wrote:
>
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] Hypervisor DoS via WARN_ON() upon page table allocation failure

Nope [1]

[1] https://lore.kernel.org/all/CA+EHjTyPxcObTOwi25QTUDbLwAYaKnWY0QJVB_aMso2=38PJUg@mail.gmail.com/

> --
>
> --- Patch [2]: [PATCH 2/4] KVM: arm64: Do not clear VM-wide SVE feature on vCPU init failure ---
> commit 1188c411e2a65143d7371d1038c2752c0f2de6c0
> Author: Fuad Tabba <fuad.tabba@linux.dev>
>
> KVM: arm64: Do not clear VM-wide SVE feature on vCPU init failure
>
> pkvm_vcpu_init_sve() clears KVM_ARM_VCPU_SVE in kvm->arch.vcpu_features
> when it fails, but vcpu_has_sve() tests KVM_ARCH_FLAG_GUEST_HAS_SVE,
> which is left set. Later vCPUs on that VM then skip the SVE setup and
> register with a NULL sve_state, which the guest's first FP access hands
> to sve_load_state().
>
> Return the error without touching vcpu_features.
>
> > diff --git a/arch/arm64/kvm/hyp/nvhe/pkvm.c b/arch/arm64/kvm/hyp/nvhe/pkvm.c
> > index c31b9d46b8b60..4340b13ee295b 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/pkvm.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/pkvm.c
>
> [ ... ]
>
> > @@ -462,24 +462,19 @@ static int pkvm_vcpu_init_sve(struct pkvm_hyp_vcpu *hyp_vcpu, struct kvm_vcpu *h
> >       sve_max_vl = min(READ_ONCE(host_vcpu->arch.sve_max_vl), kvm_host_sve_max_vl);
> >       sve_state = kern_hyp_va(READ_ONCE(host_vcpu->arch.sve_state));
> >
> > -     if (!sve_vl_valid(sve_max_vl) || !sve_state) {
> > -             ret = -EINVAL;
> > -             goto err;
> > -     }
> > +     if (!sve_vl_valid(sve_max_vl) || !sve_state)
> > +             return -EINVAL;
> >
> >       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;
> > +             return ret;
>
> [Severity: High]
> This is a pre-existing issue, but can the call to hyp_pin_shared_mem()
> trigger a hypervisor panic if EL2 memory is exhausted?
>
> Looking at hyp_pin_shared_mem() in arch/arm64/kvm/hyp/nvhe/mem_protect.c,
> it wraps the mapping allocation in a WARN_ON:
>
>         if (p->refcount == 1)
>                 WARN_ON(pkvm_create_mappings_locked((void *)cur,
>                                                     (void *)cur + PAGE_SIZE,
>                                                     PAGE_HYP));
>
> At EL2 under nVHE/pKVM, WARN_ON() expands to a BRK instruction which panics
> the hypervisor and brings down the host.
>
> Since host userspace can repeatedly invoke KVM ioctls to create VMs or vCPUs
> and exhaust the bounded EL2 memory pool, pkvm_create_mappings_locked()
> might eventually fail and return -ENOMEM.
>
> Does this allow an unprivileged host process to hit the WARN_ON and crash
> the host system?
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260825085948.1674721-1-fuad.tabba@linux.dev?part=2

Re: [PATCH 0/4] KVM: arm64: pKVM SVE vCPU init fixes

[Oliver Upton]

On Tue, 25 Aug 2026 09:59:44 +0100, Fuad Tabba wrote:
> If it's not the GIC, it's SVE. I found these while preparing the
> follow-up to the pKVM core series [1].
> 
> Patch 1 was posted on its own [2] and carries Marc's Reviewed-by. It is
> unchanged and included here because it has not been picked up yet and
> the rest of the series does not apply without it.
> 
> [...]

Applied to fixes, thanks!

[1/4] KVM: arm64: Validate the SVE vector length in pkvm_vcpu_init_sve()
      https://git.kernel.org/kvmarm/kvmarm/c/2a2eb10795a1
[2/4] KVM: arm64: Do not clear VM-wide SVE feature on vCPU init failure
      https://git.kernel.org/kvmarm/kvmarm/c/a1b3c788ad31
[3/4] KVM: arm64: Key unpin_host_sve_state() on the state it unpins
      https://git.kernel.org/kvmarm/kvmarm/c/0d62fbf34d8f
[4/4] KVM: arm64: Derive GUEST_HAS_SVE from the SVE feature bit at EL2
      https://git.kernel.org/kvmarm/kvmarm/c/4f16c5fc8dc4

--
Best,
Oliver