Re: [PATCH v5 14/18] KVM: arm64: Alloc pkvm_hyp_vcpu using pKVM heap allocator

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Loss of memory cgroup (memcg) accounting for hypervisor heap top-ups enables host memory exhaustion (DoS).
--

commit 1ea96bec624ff9de3986b5d4e5708b17bd70343c
Author: Vincent Donnefort <vdonnefort@google.com>

KVM: arm64: Alloc pkvm_hyp_vcpu using pKVM heap allocator

This patch transitions the allocation of the hypervisor vCPU state structure
(pkvm_hyp_vcpu) from the host to the hypervisor using the new pKVM heap
allocator. The host now uses pkvm_call_hyp_req() to invoke
__pkvm_create_hyp_vcpu, which automatically handles top-up requests if the
hypervisor runs out of heap memory.

> diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c
> index 8505965dbfb21..36e677e51f7d6 100644
> --- a/arch/arm64/kvm/pkvm.c
> +++ b/arch/arm64/kvm/pkvm.c
[ ... ]
> @@ -174,28 +174,19 @@ static void __pkvm_destroy_hyp_vm(struct kvm *kvm)
[ ... ]
>  static int __pkvm_create_hyp_vcpu(struct kvm_vcpu *vcpu)
>  {
> -	size_t hyp_vcpu_sz = PAGE_ALIGN(PKVM_HYP_VCPU_SIZE);
>  	pkvm_handle_t handle = vcpu->kvm->arch.pkvm.handle;
> -	void *hyp_vcpu;
>  	int ret;
>  
>  	init_hyp_stage2_memcache(&vcpu->arch.pkvm_memcache);
>  
> -	hyp_vcpu = alloc_pages_exact(hyp_vcpu_sz, GFP_KERNEL_ACCOUNT);
> -	if (!hyp_vcpu)
> -		return -ENOMEM;
> -
> -	ret = kvm_call_hyp_nvhe(__pkvm_init_vcpu, handle, vcpu, hyp_vcpu);
> +	ret = pkvm_call_hyp_req(__pkvm_init_vcpu, handle, vcpu);

[Severity: High]
Does this change lose memory cgroup (memcg) accounting for the hypervisor vCPU
allocations?

Previously, alloc_pages_exact() used GFP_KERNEL_ACCOUNT directly, ensuring
the allocation was charged to the caller's memcg. With this patch, the
allocation transitions to the EL2 heap. If the heap is exhausted,
pkvm_call_hyp_req() triggers a top-up request.

However, it appears the top-up path handles the allocation without the memcg
accounting flag. For instance, when the EL2 heap needs memory:

arch/arm64/kvm/pkvm.c:pkvm_hyp_topup() {
	init_hyp_memcache(&mc);
	ret = topup_hyp_memcache(&mc, nr_pages);
	...
}

Because init_hyp_memcache() explicitly omits the HYP_MEMCACHE_ACCOUNT_KMEMCG
flag, the subsequent allocation in hyp_mc_alloc_fn() uses GFP_KERNEL instead
of GFP_KERNEL_ACCOUNT:

arch/arm64/kvm/mmu.c:hyp_mc_alloc_fn() {
	gfp = memcache->flags & HYP_MEMCACHE_ACCOUNT_KMEMCG ? GFP_KERNEL_ACCOUNT : GFP_KERNEL;
	addr = (void *)__get_free_page(gfp);
	...
}

Could this allow an unprivileged container with access to /dev/kvm to bypass
its memory limits by repeatedly creating VMs and VCPUs, potentially leading to
host memory exhaustion?

>  	if (!ret)
>  		vcpu_set_flag(vcpu, VCPU_PKVM_FINALIZED);
> -	else
> -		free_pages_exact(hyp_vcpu, hyp_vcpu_sz);
>  
>  	return ret;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260901080941.997769-1-vdonnefort@google.com?part=14