Re: [syzbot] [mm?] WARNING in ep_write_iter

[Alan Stern]

On Sun, Aug 16, 2026 at 08:13:16PM -0400, Zi Yan wrote:
> On Sun Aug 16, 2026 at 7:32 PM EDT, Alan Stern wrote:
> > On Sun, Aug 16, 2026 at 05:47:34PM -0400, Zi Yan wrote:
> >> On Sun Aug 16, 2026 at 4:52 PM EDT, Andrew Morton wrote:
> >> > On Sun, 16 Aug 2026 12:25:48 -0700 syzbot <syzbot+805630f1453e490427fa@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> >> >
> >> >> Hello,
> >> >> 
> >> >> syzbot found the following issue on:
> >> >> 
> >> >> HEAD commit:    3d6d817622b0 Merge tag 'scsi-fixes' of git://git.kernel.or..
> >> >> git tree:       upstream
> >> >> console output: https://syzkaller.appspot.com/x/log.txt?x=15927479580000
> >> >> kernel config:  https://syzkaller.appspot.com/x/.config?x=a59830cba91a1981
> >> >> dashboard link: https://syzkaller.appspot.com/bug?extid=805630f1453e490427fa
> >> >> compiler:       Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
> >> >> 
> >> >> Unfortunately, I don't have any reproducer for this issue yet.
> >> >> 
> >> >> Downloadable assets:
> >> >> disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-3d6d8176.raw.xz
> >> >> vmlinux: https://storage.googleapis.com/syzbot-assets/d19e0514c02a/vmlinux-3d6d8176.xz
> >> >> kernel image: https://storage.googleapis.com/syzbot-assets/f6da706811f4/bzImage-3d6d8176.xz
> >> >> 
> >> >> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> >> >> Reported-by: syzbot+805630f1453e490427fa@xxxxxxxxxxxxxxxxxxxxxxxxx
> >> >> 
> >> >> gadgetfs: bound to dummy_udc driver
> >> >> ------------[ cut here ]------------
> >> >> 1
> >> >> WARNING: mm/page_alloc.c:5280 at __alloc_frozen_pages_noprof+0x2ce/0x380 mm/page_alloc.c:5280, CPU#0: syz.0.0/5319
> >> >
> >> > Thanks.  drivers/usb/gadget is the offender.
> >> >
> >> > Gemini sums it up well.  "ep_write_iter() needs a bounds check prior to
> >> > memory allocation".  https://share.gemini.google/5NzjyttO0ULc
> >> >
> >> > I expect an easy fix would be
> >> 
> >> Maybe it is better to stop asking kmalloc for unreasonable len:
> >> 
> >> 
> >> diff --git a/drivers/usb/gadget/legacy/inode.c b/drivers/usb/gadget/legacy/inode.c
> >> index d87a8ab515107..20905f254968f 100644
> >> --- a/drivers/usb/gadget/legacy/inode.c
> >> +++ b/drivers/usb/gadget/legacy/inode.c
> >> @@ -645,6 +645,9 @@ ep_write_iter(struct kiocb *iocb, struct iov_iter *from)
> >>  	ssize_t value;
> >>  	char *buf;
> >>  
> >> +	if (len > KMALLOC_MAX_SIZE)
> >> +		return -EINVAL;
> >
> > Is there any reason to think that KMALLOC_MAX_SIZE is a good limit?  The 
> > allocation could still fail, and you'd still get a WARNing.
> 
> KMALLOC_MAX_SIZE uses MAX_PAGE_ORDER, anything bigger than that will be
> rejected by page allocator. This warning comes out because of it. This
> if solves the exact issue here.

Are you saying that if len < KMALLOC_MAX_SIZE and the allocation fails, 
the kernel won't WARN?

> > I prefer Andrew's first suggestion.  If the user asks the kernel to copy 
> > too much data, just fail -- with no warning.
> 
> __GFP_WARN gets rid of all other warnings, even if user asks for a
> reasonable size. Why use such a big hammer?

Because on many systems, WARN causes the kernel to crash.  You don't 
want the entire system to crash just because the user asked for more 
memory than was available.

Alan Stern