Re: [PATCH] mm/slab: reject unsupported kmalloc sizes

[Zi Yan]

On Wed Aug 26, 2026 at 9:36 AM EDT, David Laight wrote:
> On Wed, 26 Aug 2026 11:28:12 +0200
> "Vlastimil Babka (SUSE)" <vbabka@xxxxxxxxxx> wrote:
>
>> On 8/17/26 22:40, Zi Yan wrote:
>> > kmalloc is used to allocate physically contiguous memory for kernel
>> > allocations. For requests larger than KMALLOC_MAX_CACHE_SIZE, kmalloc uses
>> > the page allocator and can only support up to KMALLOC_MAX_SIZE. For request
>> > sizes bigger than KMALLOC_MAX_SIZE, the page allocator can emit a WARN
>> > because kmalloc allocates an order greater than MAX_PAGE_ORDER. Systems
>> > with panic_on_warn=1 crash because of this WARN. Fix it by rejecting any
>> > kmalloc size bigger than KMALLOC_MAX_SIZE.
>> > 
>> > Fixes: aadb4bc4a1f9 ("SLUB: direct pass through of page size or higher kmalloc requests")
>> > Reported-by: syzbot+805630f1453e490427fa@xxxxxxxxxxxxxxxxxxxxxxxxx
>> > Closes: https://lore.kernel.org/all/6a820ebc.9ebadd4d.20b15e.001b.GAE@xxxxxxxxxx/
>> > Tested-by: syzbot+805630f1453e490427fa@xxxxxxxxxxxxxxxxxxxxxxxxx
>> > Signed-off-by: Zi Yan <ziy@xxxxxxxxxx>
>> > Cc: stable@xxxxxxxxxxxxxxx
>> > ---
>> > It fixes a page allocator warning (order > MAX_PAGE_ORDER) when gadgetfs
>> > requests excessively large memory from kmalloc. Instead of adding
>> > __GFP_NOWARN to suppress the warning, as was done for usbfs[1], change
>> > kmalloc to return NULL without a warning for this specific issue.
>> > 
>> > [1] commit 4f2629ea67e72 ("USB: usbfs: Don't WARN about excessively large memory allocations")  
>> 
>> So I checked and for kvmalloc() we have in __kvmalloc_node_noprof()
>> 
>>         /* Don't even allow crazy sizes */
>>         if (unlikely(size > INT_MAX)) {
>>                 WARN_ON_ONCE(!(flags & __GFP_NOWARN));
>>                 return NULL;
>>         }
>> 
>> This comes from Linus in commit 7661809d493b4. I'd do the same thing here
>> then. Thus there would be a useful warning for e.g. development mistakes
>> resulting in the size to be unexpectedly high.

You mean kmalloc should also have this check?

>> 
>> Callers passing size that comes from userspace or similar untrusted source
>> can either pass __GFP_NOWARN or sanitize the size to what they expect to be
>> sane (which is context dependent and I assume actually way lower than
>> kmalloc limits in practice). Note that passing even sizes within but close
>> to/at the limit, trusting blindly some external source, can succeed the
>> allocations but effectively DoS the system with heavy reclaim/compaction. So
>> caller sanitization should still be preferred IMHO.
>
> Indeed, and sanitising the values early on saves all the size_add() and
> size_mult() operations (that are just saturating maths) but still let
> through the 'DoS the system' sizes.

Yes, I am all for santizing inputs.

> Mostly the actual maximum size is actually small. I suspect limits like
> 64k, 1M or 16M would be appropriate.

I agree that the limit you suggested is better. One thing to consider is
that Mike is converting all __get_free_pages() to kmalloc[1], so the
limit might end up to be 2^MAX_PAGE_ORDER, matching the page allocator
limit.

[1] https://lore.kernel.org/all/aip7Y3UHmXsdX8OH@xxxxxxxxxx/

>
> David
>
>> Some of the recent
>> arguments from Linus [1] would apply to this too, I think.
>> 
>> [1]
>> https://lore.kernel.org/all/CAHk-=wiSmgwwLKCqJwGS-dVHnSLU8W+7q1UQq-G9=TBGGZbuhQ@xxxxxxxxxxxxxx/
>> 
>> > ---
>> >  mm/slub.c | 7 ++++++-
>> >  1 file changed, 6 insertions(+), 1 deletion(-)
>> > 
>> > diff --git a/mm/slub.c b/mm/slub.c
>> > index 0337e60db5ace..a3071f4ef1945 100644
>> > --- a/mm/slub.c
>> > +++ b/mm/slub.c
>> > @@ -5263,7 +5263,12 @@ static void *___kmalloc_large_node(size_t size, gfp_t flags, int node)
>> >  {
>> >  	struct page *page;
>> >  	void *ptr = NULL;
>> > -	unsigned int order = get_order(size);
>> > +	unsigned int order;
>> > +
>> > +	if (size > KMALLOC_MAX_SIZE)
>> > +		return NULL;
>> > +
>> > +	order = get_order(size);
>> >  
>> >  	if (unlikely(flags & GFP_SLAB_BUG_MASK))
>> >  		flags = kmalloc_fix_flags(flags);
>> > 
>> > ---
>> > base-commit: 8d3ae59288f1e7d58d76558a6ee96d533bc5019f
>> > change-id: 20260817-limit_kmalloc_size-3a4a2c73beac
>> > 
>> > Best regards,
>> > --  
>> > Yan, Zi
>> >   
>> 
>> 




-- 
Best Regards,
Yan, Zi