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

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 <[email protected]> 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: [email protected]
> >> 
> >> 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.

I prefer Andrew's first suggestion.  If the user asks the kernel to copy 
too much data, just fail -- with no warning.

Alan Stern