The Linux Kernel Mailing List
 help / color / mirror / Atom feed
* [PATCH] mm/slab: reject unsupported kmalloc sizes
@ 2026-08-17 20:40 Zi Yan
  2026-08-18  2:59 ` Alan Stern
  2026-08-26  9:28 ` Vlastimil Babka (SUSE)
  0 siblings, 2 replies; 4+ messages in thread
From: Zi Yan @ 2026-08-17 20:40 UTC (permalink / raw)
  To: Vlastimil Babka, Harry Yoo, Andrew Morton, Hao Li,
	Christoph Lameter, David Rientjes, Roman Gushchin, Alan Stern,
	Greg Kroah-Hartman
  Cc: linux-mm, linux-kernel, linux-usb, syzbot+805630f1453e490427fa,
	Zi Yan, stable

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


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] mm/slab: reject unsupported kmalloc sizes
  2026-08-17 20:40 [PATCH] mm/slab: reject unsupported kmalloc sizes Zi Yan
@ 2026-08-18  2:59 ` Alan Stern
  2026-08-18 23:46   ` Zi Yan
  2026-08-26  9:28 ` Vlastimil Babka (SUSE)
  1 sibling, 1 reply; 4+ messages in thread
From: Alan Stern @ 2026-08-18  2:59 UTC (permalink / raw)
  To: Zi Yan
  Cc: Vlastimil Babka, Harry Yoo, Andrew Morton, Hao Li,
	Christoph Lameter, David Rientjes, Roman Gushchin,
	Greg Kroah-Hartman, linux-mm, linux-kernel, linux-usb,
	syzbot+805630f1453e490427fa, stable

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] mm/slab: reject unsupported kmalloc sizes
  2026-08-18  2:59 ` Alan Stern
@ 2026-08-18 23:46   ` Zi Yan
  0 siblings, 0 replies; 4+ messages in thread
From: Zi Yan @ 2026-08-18 23:46 UTC (permalink / raw)
  To: Alan Stern
  Cc: Vlastimil Babka, Harry Yoo, Andrew Morton, Hao Li,
	Christoph Lameter, David Rientjes, Roman Gushchin,
	Greg Kroah-Hartman, linux-mm, linux-kernel, linux-usb,
	syzbot+805630f1453e490427fa, stable

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] mm/slab: reject unsupported kmalloc sizes
  2026-08-17 20:40 [PATCH] mm/slab: reject unsupported kmalloc sizes Zi Yan
  2026-08-18  2:59 ` Alan Stern
@ 2026-08-26  9:28 ` Vlastimil Babka (SUSE)
  1 sibling, 0 replies; 4+ messages in thread
From: Vlastimil Babka (SUSE) @ 2026-08-26  9:28 UTC (permalink / raw)
  To: Zi Yan, Harry Yoo, Andrew Morton, Hao Li, Christoph Lameter,
	David Rientjes, Roman Gushchin, Alan Stern, Greg Kroah-Hartman
  Cc: linux-mm, linux-kernel, linux-usb, syzbot+805630f1453e490427fa,
	stable

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
> 


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2026-08-26  9:28 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-17 20:40 [PATCH] mm/slab: reject unsupported kmalloc sizes Zi Yan
2026-08-18  2:59 ` Alan Stern
2026-08-18 23:46   ` Zi Yan
2026-08-26  9:28 ` Vlastimil Babka (SUSE)

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox