Re: [PATCH] RISC-V: KVM: Fix PMU event info array size overflow

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Guest-controlled large allocation lacks __GFP_NOWARN and __GFP_ACCOUNT, allowing host log spam and memcg limit bypass.
--

--- Patch [1]: [PATCH] RISC-V: KVM: Fix PMU event info array size overflow ---
commit f0a5b0643b60a1981804276ca1f91780cd681469
Author: Guidong Han <2045gemini@gmail.com>

RISC-V: KVM: Fix PMU event info array size overflow

The patch prevents an integer overflow when calculating shmem_size from
guest-controlled num_events in the SBI PMU EVENT_GET_INFO handler. It
introduces check_mul_overflow and rejects sizes beyond KMALLOC_MAX_SIZE.

> diff --git a/arch/riscv/kvm/vcpu_pmu.c b/arch/riscv/kvm/vcpu_pmu.c
> index bb46dcbfb24da..8b489fc3051f4 100644
> --- a/arch/riscv/kvm/vcpu_pmu.c
> +++ b/arch/riscv/kvm/vcpu_pmu.c

[ ... ]

> @@ -479,16 +481,21 @@ int kvm_riscv_vcpu_pmu_event_info(struct kvm_vcpu *vcpu, unsigned long saddr_low
>  				  unsigned long flags, struct kvm_vcpu_sbi_return *retdata)
>  {
>  	struct riscv_pmu_event_info *einfo = NULL;
> -	int shmem_size = num_events * sizeof(*einfo);
> +	size_t shmem_size;
>  	gpa_t shmem;
>  	u32 eidx, etype;
>  	u64 econfig;
>  	int ret;
>  
> -	if (flags != 0 || (saddr_low & (SZ_16 - 1) || num_events == 0)) {
> +	if (flags != 0 || (saddr_low & (SZ_16 - 1)) || num_events == 0 ||
> +	    check_mul_overflow(num_events, sizeof(*einfo), &shmem_size)) {
>  		ret = SBI_ERR_INVALID_PARAM;
>  		goto out;
>  	}
> +	if (shmem_size > KMALLOC_MAX_SIZE) {
> +		ret = SBI_ERR_FAILURE;
> +		goto out;
> +	}

[Severity: High]
This is a pre-existing issue, but is it safe to allow a guest-controlled
allocation up to KMALLOC_MAX_SIZE using kzalloc() without __GFP_ACCOUNT
and __GFP_NOWARN?

Later in kvm_riscv_vcpu_pmu_event_info(), the code does:

	einfo = kzalloc(shmem_size, GFP_KERNEL);

Since the allocation uses GFP_KERNEL without __GFP_ACCOUNT, this memory is
not charged to the guest's memory cgroup. Could an untrusted guest coordinate
concurrent SBI_EXT_PMU_EVENT_GET_INFO hypercalls across multiple vCPUs to
temporarily hoard host memory, potentially causing a host OOM?

Additionally, without __GFP_NOWARN, won't allocation failures for these
high-order pages on a fragmented system generate rate-limited page
allocation failure stack traces, causing host log spam?

Since these allocations can be large and are guest-driven, would it be better
to use kvcalloc() with GFP_KERNEL_ACCOUNT | __GFP_NOWARN so it falls back to
vmalloc() if physical memory is fragmented?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260718153620.829378-1-2045gemini@gmail.com?part=1