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

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

[Andrew Morton]

On Sun, 16 Aug 2026 12:25:48 -0700 syzbot <syzbot+805630f1453e490427fa@syzkaller.appspotmail.com> 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@syzkaller.appspotmail.com
> 
> 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

--- a/drivers/usb/gadget/legacy/inode.c~a
+++ a/drivers/usb/gadget/legacy/inode.c
@@ -666,7 +666,7 @@ ep_write_iter(struct kiocb *iocb, struct
 		return -EBADMSG;
 	}
 
-	buf = kmalloc(len, GFP_KERNEL);
+	buf = kmalloc(len, GFP_KERNEL|__GFP_NOWARN);
 	if (unlikely(!buf)) {
 		mutex_unlock(&epdata->lock);
 		return -ENOMEM;

or do what Gemini said.  Me, I'll add some cc's and run away.


> Modules linked in:
> CPU: 0 UID: 0 PID: 5319 Comm: syz.0.0 Not tainted syzkaller #0 PREEMPT(full) 
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
> RIP: 0010:__alloc_frozen_pages_noprof+0x2ce/0x380 mm/page_alloc.c:5280
> Code: 74 10 4c 89 e7 89 54 24 0c e8 0e 2c 0e 00 8b 54 24 0c 49 83 3c 24 00 0f 85 ab fe ff ff e9 ac fe ff ff c6 05 95 d2 18 0e 01 90 <0f> 0b 90 e9 17 ff ff ff a9 00 00 08 00 48 8b 4c 24 10 4c 8d 44 24
> RSP: 0018:ffffc9000e13fa20 EFLAGS: 00010246
> RAX: ffffc9000e13fa00 RBX: 0000000000000013 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffc9000e13fa88
> RBP: ffffc9000e13fb08 R08: ffffc9000e13fa87 R09: 0000000000000000
> R10: ffffc9000e13fa60 R11: fffff52001c27f51 R12: 0000000000000000
> R13: 1ffff92001c27f48 R14: 0000000000040cc0 R15: dffffc0000000000
> FS:  00007f6f4a58c6c0(0000) GS:ffff88808c549000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00002000000010a0 CR3: 000000004323d000 CR4: 0000000000352ef0
> Call Trace:
>  <TASK>
>  alloc_pages_mpol+0x212/0x380 mm/mempolicy.c:2490
>  ___kmalloc_large_node+0x4c/0x120 mm/slub.c:5274
>  __kmalloc_large_node_noprof+0x18/0x90 mm/slub.c:5305
>  __do_kmalloc_node mm/slub.c:5322 [inline]
>  __kmalloc_noprof+0x405/0x720 mm/slub.c:5359
>  _kmalloc_noprof include/linux/slab.h:992 [inline]
>  ep_write_iter+0x1bc/0x500 drivers/usb/gadget/legacy/inode.c:669
>  new_sync_write fs/read_write.c:595 [inline]
>  vfs_write+0x612/0xba0 fs/read_write.c:687
>  ksys_write+0x150/0x270 fs/read_write.c:739
>  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
>  do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7f6f4979e0d9
> Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007f6f4a58bfe8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
> RAX: ffffffffffffffda RBX: 00007f6f49a25fa0 RCX: 00007f6f4979e0d9
> RDX: 00000000ffffffb9 RSI: 0000000000000000 RDI: 0000000000000004
> RBP: 00007f6f49835024 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> R13: 00007f6f49a26038 R14: 00007f6f49a25fa0 R15: 00007ffc6cf49328
>  </TASK>
> 

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

[Zi Yan]

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@syzkaller.appspotmail.com> 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@syzkaller.appspotmail.com
>> 
>> 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;
+
 	if ((value = get_ready_ep(file->f_flags, epdata, true)) < 0)
 		return value;

>
> --- a/drivers/usb/gadget/legacy/inode.c~a
> +++ a/drivers/usb/gadget/legacy/inode.c
> @@ -666,7 +666,7 @@ ep_write_iter(struct kiocb *iocb, struct
>  		return -EBADMSG;
>  	}
>  
> -	buf = kmalloc(len, GFP_KERNEL);
> +	buf = kmalloc(len, GFP_KERNEL|__GFP_NOWARN);
>  	if (unlikely(!buf)) {
>  		mutex_unlock(&epdata->lock);
>  		return -ENOMEM;
>
> or do what Gemini said.  Me, I'll add some cc's and run away.
>
>
>> Modules linked in:
>> CPU: 0 UID: 0 PID: 5319 Comm: syz.0.0 Not tainted syzkaller #0 PREEMPT(full) 
>> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
>> RIP: 0010:__alloc_frozen_pages_noprof+0x2ce/0x380 mm/page_alloc.c:5280
>> Code: 74 10 4c 89 e7 89 54 24 0c e8 0e 2c 0e 00 8b 54 24 0c 49 83 3c 24 00 0f 85 ab fe ff ff e9 ac fe ff ff c6 05 95 d2 18 0e 01 90 <0f> 0b 90 e9 17 ff ff ff a9 00 00 08 00 48 8b 4c 24 10 4c 8d 44 24
>> RSP: 0018:ffffc9000e13fa20 EFLAGS: 00010246
>> RAX: ffffc9000e13fa00 RBX: 0000000000000013 RCX: 0000000000000000
>> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffc9000e13fa88
>> RBP: ffffc9000e13fb08 R08: ffffc9000e13fa87 R09: 0000000000000000
>> R10: ffffc9000e13fa60 R11: fffff52001c27f51 R12: 0000000000000000
>> R13: 1ffff92001c27f48 R14: 0000000000040cc0 R15: dffffc0000000000
>> FS:  00007f6f4a58c6c0(0000) GS:ffff88808c549000(0000) knlGS:0000000000000000
>> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: 00002000000010a0 CR3: 000000004323d000 CR4: 0000000000352ef0
>> Call Trace:
>>  <TASK>
>>  alloc_pages_mpol+0x212/0x380 mm/mempolicy.c:2490
>>  ___kmalloc_large_node+0x4c/0x120 mm/slub.c:5274
>>  __kmalloc_large_node_noprof+0x18/0x90 mm/slub.c:5305
>>  __do_kmalloc_node mm/slub.c:5322 [inline]
>>  __kmalloc_noprof+0x405/0x720 mm/slub.c:5359
>>  _kmalloc_noprof include/linux/slab.h:992 [inline]
>>  ep_write_iter+0x1bc/0x500 drivers/usb/gadget/legacy/inode.c:669
>>  new_sync_write fs/read_write.c:595 [inline]
>>  vfs_write+0x612/0xba0 fs/read_write.c:687
>>  ksys_write+0x150/0x270 fs/read_write.c:739
>>  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
>>  do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94
>>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
>> RIP: 0033:0x7f6f4979e0d9
>> Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
>> RSP: 002b:00007f6f4a58bfe8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
>> RAX: ffffffffffffffda RBX: 00007f6f49a25fa0 RCX: 00007f6f4979e0d9
>> RDX: 00000000ffffffb9 RSI: 0000000000000000 RDI: 0000000000000004
>> RBP: 00007f6f49835024 R08: 0000000000000000 R09: 0000000000000000
>> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
>> R13: 00007f6f49a26038 R14: 00007f6f49a25fa0 R15: 00007ffc6cf49328
>>  </TASK>
>> 




-- 
Best Regards,
Yan, Zi

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

[Alan Stern]

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@syzkaller.appspotmail.com> 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@syzkaller.appspotmail.com
> >> 
> >> 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

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

[Zi Yan]

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@syzkaller.appspotmail.com> 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@syzkaller.appspotmail.com
>> >> 
>> >> 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.

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


-- 
Best Regards,
Yan, Zi

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@syzkaller.appspotmail.com> 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@syzkaller.appspotmail.com
> >> >> 
> >> >> 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

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@syzkaller.appspotmail.com> 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@syzkaller.appspotmail.com
>> >> >> 
>> >> >> 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

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

[Andrew Morton]

On Sun, 16 Aug 2026 21:47:58 -0400 "Zi Yan" <ziy@nvidia.com> wrote:

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

I assume Alan is referring to panic_on_warn.

Heaven knows how common panic_on_warn usage is.  Gemini tells me "There
is no exact global headcount or precise user metric for how many people
use panic_on_warn.  However, the setting is widely enabled across a few
billion Android devices and many cloud/server provider host kernels
where automated failover makes a full reboot preferable to running with
an unknown warning state".

So I do think that WARNs are more serious than we (mm developers) tend
to assume.

So we just shouldn't permit userspace to trivially trigger a
page-allocation WARN.  Especially if the caller is perfectly capable of
handling an ENOMEM allocation failure, as appears to be the case with
usb-gadget.

(Does usb-gadget actually get used by Android?  Surely not by cloud
providers!)

(Can this WARN be triggered by unprivileged userspace?  I didn't look,
this matters a lot).

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

Right.  As long as it doesn't trigger a WARN!




Perhaps we should revisit this.

Why are we emitting a WARN if an allocation fails, given that this will
often panic the kernel?  Should we on the core MM side dial that back
to a pr_warn() and a helpful backtrace?