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

[Vlastimil Babka (SUSE)]

On 8/26/26 11:52 PM, Zi Yan wrote:
> On Wed Aug 26, 2026 at 5:47 PM EDT, Harry Yoo wrote:
>> On Wed, Aug 26, 2026 at 11:28:12AM +0000, Vlastimil Babka (SUSE) 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.
>>
>> But the purpose of this patch is to avoid the warning in the page
>> allocator. Should we fix this in the caller (gadgetfs) then? 
> 
> It is fixed by: https://lore.kernel.org/all/20260820223719.A4A3C1F000E9@xxxxxxxxxxxxxxx/
> 
> Please disregard this patch, but we can keep the discussion going.

I still think this patch has some value if done as proposed above. Yes
in practice it will just replace the page allocator's warning with a
different warning, but IMHO it's "nicer" if kmalloc() sanitizes its own
requests to the page allocator, using the KMALLOC_MAX_SIZE value.

>>
>>> Thus there would be a useful warning for e.g. development mistakes
>>> resulting in the size to be unexpectedly high.
>>>
>>> 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. 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/
> 
> 
> 
>