[PATCH] mm/slab: reject unsupported kmalloc sizes

[PATCH] mm/slab: reject unsupported kmalloc sizes

[Zi Yan]

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@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/6a820ebc.9ebadd4d.20b15e.001b.GAE@google.com/
Tested-by: syzbot+805630f1453e490427fa@syzkaller.appspotmail.com
Signed-off-by: Zi Yan <ziy@nvidia.com>
Cc: stable@vger.kernel.org
---
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")
---
 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

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

[Alan Stern]

On Mon, Aug 17, 2026 at 04:40:18PM -0400, 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@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/all/6a820ebc.9ebadd4d.20b15e.001b.GAE@google.com/
> Tested-by: syzbot+805630f1453e490427fa@syzkaller.appspotmail.com
> Signed-off-by: Zi Yan <ziy@nvidia.com>
> Cc: stable@vger.kernel.org
> ---
> 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")

Thanks for doing this.  If you like, I can write a follow-up patch to 
remove the __GFP_NOWARN added in 4f2629ea67e72, now that it isn't needed 
any more.

Alan Stern

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

[Zi Yan]

On Mon Aug 17, 2026 at 10:59 PM EDT, Alan Stern wrote:
> On Mon, Aug 17, 2026 at 04:40:18PM -0400, 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@syzkaller.appspotmail.com
>> Closes: https://lore.kernel.org/all/6a820ebc.9ebadd4d.20b15e.001b.GAE@google.com/
>> Tested-by: syzbot+805630f1453e490427fa@syzkaller.appspotmail.com
>> Signed-off-by: Zi Yan <ziy@nvidia.com>
>> Cc: stable@vger.kernel.org
>> ---
>> 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")
>
> Thanks for doing this.  If you like, I can write a follow-up patch to 
> remove the __GFP_NOWARN added in 4f2629ea67e72, now that it isn't needed 
> any more.

Sure. Once the patch gets an Ack or Rb from a maintainer and Andrew
picks it up, feel free to send a cleanup patch. Thanks.

-- 
Best Regards,
Yan, Zi

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

[Vlastimil Babka (SUSE)]

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@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/all/6a820ebc.9ebadd4d.20b15e.001b.GAE@google.com/
> Tested-by: syzbot+805630f1453e490427fa@syzkaller.appspotmail.com
> Signed-off-by: Zi Yan <ziy@nvidia.com>
> Cc: stable@vger.kernel.org
> ---
> 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.

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@mail.gmail.com/

> ---
>  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
> 

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

[David Laight]

On Wed, 26 Aug 2026 11:28:12 +0200
"Vlastimil Babka (SUSE)" <vbabka@kernel.org> 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@syzkaller.appspotmail.com
> > Closes: https://lore.kernel.org/all/6a820ebc.9ebadd4d.20b15e.001b.GAE@google.com/
> > Tested-by: syzbot+805630f1453e490427fa@syzkaller.appspotmail.com
> > Signed-off-by: Zi Yan <ziy@nvidia.com>
> > Cc: stable@vger.kernel.org
> > ---
> > 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.
> 
> 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.
Mostly the actual maximum size is actually small. I suspect limits like
64k, 1M or 16M would be appropriate.

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@mail.gmail.com/
> 
> > ---
> >  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
> >   
> 
> 

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@kernel.org> 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@syzkaller.appspotmail.com
>> > Closes: https://lore.kernel.org/all/6a820ebc.9ebadd4d.20b15e.001b.GAE@google.com/
>> > Tested-by: syzbot+805630f1453e490427fa@syzkaller.appspotmail.com
>> > Signed-off-by: Zi Yan <ziy@nvidia.com>
>> > Cc: stable@vger.kernel.org
>> > ---
>> > 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@kernel.org/

>
> 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@mail.gmail.com/
>> 
>> > ---
>> >  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

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

[Harry Yoo]

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@syzkaller.appspotmail.com
> > Closes: https://lore.kernel.org/all/6a820ebc.9ebadd4d.20b15e.001b.GAE@google.com/
> > Tested-by: syzbot+805630f1453e490427fa@syzkaller.appspotmail.com
> > Signed-off-by: Zi Yan <ziy@nvidia.com>
> > Cc: stable@vger.kernel.org
> > ---
> > 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? 

> 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@mail.gmail.com/

-- 
Cheers,
Harry / Hyeonggon

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

[Zi Yan]

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@syzkaller.appspotmail.com
>> > Closes: https://lore.kernel.org/all/6a820ebc.9ebadd4d.20b15e.001b.GAE@google.com/
>> > Tested-by: syzbot+805630f1453e490427fa@syzkaller.appspotmail.com
>> > Signed-off-by: Zi Yan <ziy@nvidia.com>
>> > Cc: stable@vger.kernel.org
>> > ---
>> > 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@smtp.kernel.org/

Please disregard this patch, but we can keep the discussion going.


>
>> 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@mail.gmail.com/




-- 
Best Regards,
Yan, Zi

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@syzkaller.appspotmail.com
>>>> Closes: https://lore.kernel.org/all/6a820ebc.9ebadd4d.20b15e.001b.GAE@google.com/
>>>> Tested-by: syzbot+805630f1453e490427fa@syzkaller.appspotmail.com
>>>> Signed-off-by: Zi Yan <ziy@nvidia.com>
>>>> Cc: stable@vger.kernel.org
>>>> ---
>>>> 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@smtp.kernel.org/
> 
> 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@mail.gmail.com/
> 
> 
> 
> 

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

[Zi Yan]

On Thu Aug 27, 2026 at 3:47 AM EDT, Vlastimil Babka (SUSE) wrote:
> 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@syzkaller.appspotmail.com
>>>>> Closes: https://lore.kernel.org/all/6a820ebc.9ebadd4d.20b15e.001b.GAE@google.com/
>>>>> Tested-by: syzbot+805630f1453e490427fa@syzkaller.appspotmail.com
>>>>> Signed-off-by: Zi Yan <ziy@nvidia.com>
>>>>> Cc: stable@vger.kernel.org
>>>>> ---
>>>>> 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@smtp.kernel.org/
>> 
>> 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

And SLAB maintainers will be Cc'd. :)

> requests to the page allocator, using the KMALLOC_MAX_SIZE value.

Like this? Or the exact pattern as kvmalloc() is preferred?


diff --git a/mm/slub.c b/mm/slub.c
index 0337e60db5ace..b562f2a6fbbee 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 (WARN_ON_ONCE_GFP(size > KMALLOC_MAX_SIZE, flags))
+		return NULL;
+
+	order = get_order(size);
 
 	if (unlikely(flags & GFP_SLAB_BUG_MASK))
 		flags = kmalloc_fix_flags(flags);


-- 
Best Regards,
Yan, Zi

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

[Vlastimil Babka (SUSE)]

On 8/27/26 17:51, Zi Yan wrote:
> On Thu Aug 27, 2026 at 3:47 AM EDT, Vlastimil Babka (SUSE) wrote:
>> 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@syzkaller.appspotmail.com
>>>>>> Closes: https://lore.kernel.org/all/6a820ebc.9ebadd4d.20b15e.001b.GAE@google.com/
>>>>>> Tested-by: syzbot+805630f1453e490427fa@syzkaller.appspotmail.com
>>>>>> Signed-off-by: Zi Yan <ziy@nvidia.com>
>>>>>> Cc: stable@vger.kernel.org
>>>>>> ---
>>>>>> 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@smtp.kernel.org/
>>> 
>>> 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
> 
> And SLAB maintainers will be Cc'd. :)

For some people it doesn't matter if it's SLAB or PAGE ALLOCATOR :D

>> requests to the page allocator, using the KMALLOC_MAX_SIZE value.
> 
> Like this? Or the exact pattern as kvmalloc() is preferred?

LGTM. Should return NULL even with __GFP_NOWARN or if the warning has fired
and won't again, and AFAICS this does.

The kvmalloc() pattern predates WARN_ON_ONCE_GFP addition, I think.

> diff --git a/mm/slub.c b/mm/slub.c
> index 0337e60db5ace..b562f2a6fbbee 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 (WARN_ON_ONCE_GFP(size > KMALLOC_MAX_SIZE, flags))
> +		return NULL;
> +
> +	order = get_order(size);
>  
>  	if (unlikely(flags & GFP_SLAB_BUG_MASK))
>  		flags = kmalloc_fix_flags(flags);
> 
>