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

[Shubhang]

Hi Anshuman,

On Fri, 23 Oct 2026, Anshuman Khandual wrote:

> > +	if (count > ULONG_MAX >> PAGE_SHIFT)
> > +		return NULL;
>
> Could vm_map_ram() ever be called with such a large number as count ?

Yes. I checked the direct callers while respinning this.

udmabuf can build such a count from userspace-provided, page-aligned
ranges. It stores the accumulated count in ubuf->pagecount, and its
DMA-BUF vmap callback passes that value directly to vm_map_ram():

	vaddr = vm_map_ram(ubuf->pages, ubuf->pagecount, -1);

On a 32-bit PAE kernel, the default udmabuf size limit permits a count
in the overflowing range, subject to sufficient backing memory and
successful pinning. For example, 1048577 pages with 4 KiB pages is a
4 GiB + 4 KiB udmabuf request.

There is also an in-tree import route which invokes this callback.
DRM drivers using DRM_GEM_DMA_DRIVER_OPS_VMAP call dma_buf_vmap() while 
importing DMA-BUF through PRIME, which reaches udmabuf's vmap operation.

The same overflowing conversion makes udmabuf advertise a one-page DMA-BUF 
size and build an SG table with a one-page byte length. Therefore, this 
establishes that vm_map_ram() can receive a userspace-derived overflowing 
count. However, I have not found a current in-tree importer that then 
accesses the returned mapping as if it covered all 1048577 pages.

The v2 using check_mul_overflow() is here:

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

Regards,
Shubhang Kaushik