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

[Zi Yan]

On Sun Aug 16, 2026 at 9:15 PM EDT, Alan Stern wrote:
> 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?

Right. Just pr_warn() (from warn_alloc()) to tell allocation fails and
NULL is returned.

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

User asking for more memory that what is available is pretty common and
should not trigger a WARN or crash, unless you have panic_on_oom set.
You can mmap a virtual address range bigger than your physical memory
size plus your swap space and try to fault all pages in. That would
cause OOM and the system should not crash.


-- 
Best Regards,
Yan, Zi