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

[sashiko-bot@kernel.org]

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