[PATCH v2 18/18] KVM: arm64: Alloc simple_buffer_page using pKVM hyp allocator

[Vincent Donnefort]

On Wed, Jul 15, 2026 at 04:07:05PM +0100, Fuad Tabba wrote:
> On Mon, 6 Jul 2026 at 18:54, Vincent Donnefort <vdonnefort at google.com> wrote:
> 
> ...
> 
> > @@ -193,17 +211,8 @@ static bool hyp_trace_desc_is_valid(struct hyp_trace_desc *desc, size_t desc_siz
> >                 if ((void *)rb_desc + struct_size(rb_desc, page_va, rb_desc->nr_page_va) > desc_end)
> >                         return false;
> >
> > -               /* Overflow bpages backing memory? */
> > -               if (nr_bpages < rb_desc->nr_page_va)
> > -                       return false;
> > -
> > -               if (cpu >= hyp_nr_cpus)
> > -                       return false;
> > -
> >                 if (cpu != rb_desc->cpu)
> >                         return false;
> 
> Sashiko flagged this. Nothing here bounds nr_page_va from below, so
> with nr_page_va == 0 on every CPU the bpage size sums to 0.
> hyp_alloc() still hands back a chunk, but bpages_backing_size is
> stored as 0, so when init_mm() fails on nr_page_va < 3 the free path
> takes its if (!size) return and never frees it. The host can repeat
> it. Would validating nr_page_va >= 3 here work?

simple_ring_buffer_init_mm() already validates nr_page_va. And on error, we do
seem to rollback properly and hyp_free().

So I don't believe there's anything to do here.

> 
> I don't think the rest of Sashiko's note holds: the zero-size path
> succeeds rather than hitting -ENOMEM. And it's only reachable from the
> host kernel, not userspace.
> 
> Cheers,
> /fuad