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

On Sat, Jul 18, 2026 at 11:49 PM <[email protected]> wrote:
>
> 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.

You're right, this was helpful. Fixed in v2. Thanks!

> --
>
> --- Patch [1]: [PATCH] RISC-V: KVM: Fix PMU event info array size overflow ---
> commit f0a5b0643b60a1981804276ca1f91780cd681469
> Author: Guidong Han <[email protected]>
>
> 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/[email protected]?part=1