Re: [PATCH] mm/vmalloc: reject overflowing vm_map_ram page counts

[Shubhang]

Hi Dev,

On Fri, 23 Oct 2026, Dev Jain wrote:

> On 23/10/26 5:05 am, Shubhang Kaushik (Ampere) wrote:
> > vm_map_ram() converts its unsigned int page count to an unsigned long
> > byte size without checking for overflow.
> >
> > On 32-bit kernels, a count greater than ULONG_MAX >> PAGE_SHIFT wraps
> > the byte size.  vm_map_ram() passes that size to both alloc_vmap_area()
> > and vmap_pages_range(), so it can allocate and map only the wrapped
> > number of pages while returning success for the original larger request.
>
> I would expect the caller to take care of this?
>
> In vmap(), the check is count > totalram_pages(), is this check more
> appropriate to be used in vm_map_ram too?

Thanks for the review. I have addressed the conversion issue in v2
with check_mul_overflow(), as suggested by Andrew:

  https://lore.kernel.org/lkml/20261022-vmalloc-reject-overflow-v2-1-0db7a20c53f0@xxxxxxxxxx/

I do not think the totalram_pages() check in vmap() is an appropriate
replacement for the overflow check in vm_map_ram(). It is a separate
sanity check on the requested page count; it does not ensure that
count * PAGE_SIZE is representable in an unsigned long.

For example, on a 32-bit PAE kernel, totalram_pages() can exceed
ULONG_MAX >> PAGE_SHIFT, so a count can pass that check while its byte
size still overflows.

vm_map_ram() is also a separate API and performs this conversion itself,
so the check_mul_overflow() validation should remain.

Regards,
Shubhang Kaushik