[syzbot] [mm?] WARNING in ep_write_iter

[syzbot] [mm?] WARNING in ep_write_iter

[syzbot]

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


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

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?