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

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

[Alan Stern]

On Sun, Aug 16, 2026 at 07:42:13PM -0700, Andrew Morton wrote:
> 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.

Yes.

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

I do know that Greg KH has pretty strong feelings about this issue.

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

I don't think it can.  Regardless, even privileged userspace shouldn't 
be able to crash the whole system by doing something that ought to 
return a harmless error.

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

I think that would be a very good idea.  Only the caller knows whether 
an allocation failure will leave the system in an unstable state; the 
library routine shouldn't try to make this decision on its own.

Alan Stern

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

[Zi Yan]

On 17 Aug 2026, at 9:55, Alan Stern wrote:

> On Sun, Aug 16, 2026 at 07:42:13PM -0700, Andrew Morton wrote:
>> 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.
>
> Yes.

Right. That is why I said “unless you have panic_on_oom set”. So panic_on_warn
will not crash the kernel if user asks for more memory than what is available.

>
>> 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.
>
> I do know that Greg KH has pretty strong feelings about this issue.

But the warning here is when kernel user wants buddy allocator to give
what it cannot allocate, a page order > MAX_PAGE_ORDER. The warning
tells that kernel user please ask for a reasonably sized memory.

>
>> 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).
>
> I don't think it can.  Regardless, even privileged userspace shouldn't
> be able to crash the whole system by doing something that ought to
> return a harmless error.

The issue here is that the inode.c code passes the user input len without
checking to page allocator code. Capping that is a minimal requirement
to prevent untrusted userspace input getting into trusted kernel space code
easily.

>
>>> 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?
>
> I think that would be a very good idea.  Only the caller knows whether
> an allocation failure will leave the system in an unstable state; the
> library routine shouldn't try to make this decision on its own.

In this case, the WARN is emitted not because of an allocation failure,
but an invalid input to buddy allocator (order > MAX_PAGE_ORDER). The
WARN is for kernel developers, telling them their code is asking too much
free memory and core MM cannot handle it. Suppressing that means
code outside MM can abuse page allocator. Code like doing
alloc_pages(MAX_PAGE_ORDER + 1, __GFP_NOFAIL | __GFP_NOWARN) should not
exist, instead of just getting pr_warn() and failures.



Best Regards,
Yan, Zi

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

[Zi Yan]

On 17 Aug 2026, at 10:34, Zi Yan wrote:

> On 17 Aug 2026, at 9:55, Alan Stern wrote:
>
>> On Sun, Aug 16, 2026 at 07:42:13PM -0700, Andrew Morton wrote:
>>> 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.
>>
>> Yes.
>
> Right. That is why I said “unless you have panic_on_oom set”. So panic_on_warn
> will not crash the kernel if user asks for more memory than what is available.
>
>>
>>> 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.
>>
>> I do know that Greg KH has pretty strong feelings about this issue.
>
> But the warning here is when kernel user wants buddy allocator to give
> what it cannot allocate, a page order > MAX_PAGE_ORDER. The warning
> tells that kernel user please ask for a reasonably sized memory.
>
>>
>>> 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).
>>
>> I don't think it can.  Regardless, even privileged userspace shouldn't
>> be able to crash the whole system by doing something that ought to
>> return a harmless error.
>
> The issue here is that the inode.c code passes the user input len without
> checking to page allocator code. Capping that is a minimal requirement
> to prevent untrusted userspace input getting into trusted kernel space code
> easily.
>
>>
>>>> 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?
>>
>> I think that would be a very good idea.  Only the caller knows whether
>> an allocation failure will leave the system in an unstable state; the
>> library routine shouldn't try to make this decision on its own.
>
> In this case, the WARN is emitted not because of an allocation failure,
> but an invalid input to buddy allocator (order > MAX_PAGE_ORDER). The
> WARN is for kernel developers, telling them their code is asking too much
> free memory and core MM cannot handle it. Suppressing that means
> code outside MM can abuse page allocator. Code like doing
> alloc_pages(MAX_PAGE_ORDER + 1, __GFP_NOFAIL | __GFP_NOWARN) should not
> exist, instead of just getting pr_warn() and failures.

+other page allocator people

In case I am wrong.

Best Regards,
Yan, Zi

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

[Alan Stern]

On Mon, Aug 17, 2026 at 10:37:29AM -0400, Zi Yan wrote:
> On 17 Aug 2026, at 10:34, Zi Yan wrote:
> > But the warning here is when kernel user wants buddy allocator to give
> > what it cannot allocate, a page order > MAX_PAGE_ORDER. The warning
> > tells that kernel user please ask for a reasonably sized memory.

That's fine, but it doesn't have to be done in a way that will crash 
many systems.

> > The issue here is that the inode.c code passes the user input len without
> > checking to page allocator code. Capping that is a minimal requirement
> > to prevent untrusted userspace input getting into trusted kernel space code
> > easily.

I disagree.  If the memory allocators are so fragile that userspace can 
break into the kernel just by asking for too much memory, the allocators 
should be fixed.

Furthermore, it's generally recognized that library routines such as 
kmalloc() should check their own inputs rather than relying on their 
callers to do this work for them.

> >>> 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?
> >>
> >> I think that would be a very good idea.  Only the caller knows whether
> >> an allocation failure will leave the system in an unstable state; the
> >> library routine shouldn't try to make this decision on its own.
> >
> > In this case, the WARN is emitted not because of an allocation failure,
> > but an invalid input to buddy allocator (order > MAX_PAGE_ORDER). The
> > WARN is for kernel developers, telling them their code is asking too much
> > free memory and core MM cannot handle it. Suppressing that means
> > code outside MM can abuse page allocator. Code like doing
> > alloc_pages(MAX_PAGE_ORDER + 1, __GFP_NOFAIL | __GFP_NOWARN) should not
> > exist, instead of just getting pr_warn() and failures.

Again, I disagree with some of the details of this argument in this 
context.  For instance, if all kernel developers are supposed to know 
that they shouldn't ask kmalloc() for more than MAX_PAGE_ORDER at the 
risk of provoking a WARN, if this is such an important restriction, then 
shouldn't this requirement be mentioned in the kerneldoc for kmalloc()?

Regardless, if it is important to let kernel developers know that their 
code is doing something wrong, why not make the WARN conditional on 
CONFIG_EXPERT or something similar?  In other words, prevent it from 
crashing production systems.

Alan Stern

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

[Zi Yan]

On 17 Aug 2026, at 11:06, Alan Stern wrote:

> On Mon, Aug 17, 2026 at 10:37:29AM -0400, Zi Yan wrote:
>> On 17 Aug 2026, at 10:34, Zi Yan wrote:
>>> But the warning here is when kernel user wants buddy allocator to give
>>> what it cannot allocate, a page order > MAX_PAGE_ORDER. The warning
>>> tells that kernel user please ask for a reasonably sized memory.
>
> That's fine, but it doesn't have to be done in a way that will crash
> many systems.
>
>>> The issue here is that the inode.c code passes the user input len without
>>> checking to page allocator code. Capping that is a minimal requirement
>>> to prevent untrusted userspace input getting into trusted kernel space code
>>> easily.
>
> I disagree.  If the memory allocators are so fragile that userspace can
> break into the kernel just by asking for too much memory, the allocators
> should be fixed.
>
> Furthermore, it's generally recognized that library routines such as
> kmalloc() should check their own inputs rather than relying on their
> callers to do this work for them.
>
>>>>> 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?
>>>>
>>>> I think that would be a very good idea.  Only the caller knows whether
>>>> an allocation failure will leave the system in an unstable state; the
>>>> library routine shouldn't try to make this decision on its own.
>>>
>>> In this case, the WARN is emitted not because of an allocation failure,
>>> but an invalid input to buddy allocator (order > MAX_PAGE_ORDER). The
>>> WARN is for kernel developers, telling them their code is asking too much
>>> free memory and core MM cannot handle it. Suppressing that means
>>> code outside MM can abuse page allocator. Code like doing
>>> alloc_pages(MAX_PAGE_ORDER + 1, __GFP_NOFAIL | __GFP_NOWARN) should not
>>> exist, instead of just getting pr_warn() and failures.
>
> Again, I disagree with some of the details of this argument in this
> context.  For instance, if all kernel developers are supposed to know
> that they shouldn't ask kmalloc() for more than MAX_PAGE_ORDER at the
> risk of provoking a WARN, if this is such an important restriction, then
> shouldn't this requirement be mentioned in the kerneldoc for kmalloc()?


kmalloc is the normal method of allocating memory
for objects smaller than page size in the kernel.

See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/slab.h?h=v7.2#n1001

In this case, kmalloc is used to request > 4MB memory.

>
> Regardless, if it is important to let kernel developers know that their
> code is doing something wrong, why not make the WARN conditional on
> CONFIG_EXPERT or something similar?  In other words, prevent it from
> crashing production systems.



Best Regards,
Yan, Zi

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

[Alan Stern]

On Mon, Aug 17, 2026 at 11:22:47AM -0400, Zi Yan wrote:
> > Again, I disagree with some of the details of this argument in this
> > context.  For instance, if all kernel developers are supposed to know
> > that they shouldn't ask kmalloc() for more than MAX_PAGE_ORDER at the
> > risk of provoking a WARN, if this is such an important restriction, then
> > shouldn't this requirement be mentioned in the kerneldoc for kmalloc()?
> 
> 
> kmalloc is the normal method of allocating memory
> for objects smaller than page size in the kernel.

This means when you are allocating small objects, kmalloc is the normal 
way to do it.  It says nothing about what you should do when allocating 
large objects.

In particular, it doesn't say that if you ask kmalloc for more than 4 MB 
of memory, your system is likely to crash.

> See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/slab.h?h=v7.2#n1001
> 
> In this case, kmalloc is used to request > 4MB memory.
> 
> >
> > Regardless, if it is important to let kernel developers know that their
> > code is doing something wrong, why not make the WARN conditional on
> > CONFIG_EXPERT or something similar?  In other words, prevent it from
> > crashing production systems.

You didn't respond to this.

Alan Stern

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

[Greg Kroah-Hartman]

On Mon, Aug 17, 2026 at 10:34:26AM -0400, Zi Yan wrote:
> On 17 Aug 2026, at 9:55, Alan Stern wrote:
> 
> > On Sun, Aug 16, 2026 at 07:42:13PM -0700, Andrew Morton wrote:
> >> 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.
> >
> > Yes.
> 
> Right. That is why I said “unless you have panic_on_oom set”. So panic_on_warn
> will not crash the kernel if user asks for more memory than what is available.

Are you sure?  It kicks off syzbot, what prevents the oops from
happening if panic_on_warn is enabled and a warning like this happens?
Am I missing some code somewhere?

> >> 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.
> >
> > I do know that Greg KH has pretty strong feelings about this issue.
> 
> But the warning here is when kernel user wants buddy allocator to give
> what it cannot allocate, a page order > MAX_PAGE_ORDER. The warning
> tells that kernel user please ask for a reasonably sized memory.

And if panic_on_warn is enabled, like it is in billions of Linux
systems, and a user can trigger it, then you just rebooted the box,
causing a DoS and a simple way to get a CVE assigned for the problem.

> >> 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).
> >
> > I don't think it can.  Regardless, even privileged userspace shouldn't
> > be able to crash the whole system by doing something that ought to
> > return a harmless error.
> 
> The issue here is that the inode.c code passes the user input len without
> checking to page allocator code. Capping that is a minimal requirement
> to prevent untrusted userspace input getting into trusted kernel space code
> easily.

But why would inode.c know what the page allocation max is?  We have put
arbitrary bounds in other places where you can cause large allocations
from userspace (like in usbfs), and if that's needed here, great, we can
do that too.  But don't tie that to the mm core values as those can
change over time.


thanks,

greg k-h

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

[Zi Yan]

On 17 Aug 2026, at 11:06, Greg Kroah-Hartman wrote:

> On Mon, Aug 17, 2026 at 10:34:26AM -0400, Zi Yan wrote:
>> On 17 Aug 2026, at 9:55, Alan Stern wrote:
>>
>>> On Sun, Aug 16, 2026 at 07:42:13PM -0700, Andrew Morton wrote:
>>>> 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.
>>>
>>> Yes.
>>
>> Right. That is why I said “unless you have panic_on_oom set”. So panic_on_warn
>> will not crash the kernel if user asks for more memory than what is available.
>
> Are you sure?  It kicks off syzbot, what prevents the oops from
> happening if panic_on_warn is enabled and a warning like this happens?
> Am I missing some code somewhere?

usb’s inode.c uses kmalloc to allocate > order 10 memory, namely >4MB. This
caused the warning.

kmalloc’s doc says:

kmalloc is the normal method of allocating memory
for objects smaller than page size in the kernel.

Shouldn’t usb inode.c use a proper memory allocation API?

>
>>>> 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.
>>>
>>> I do know that Greg KH has pretty strong feelings about this issue.
>>
>> But the warning here is when kernel user wants buddy allocator to give
>> what it cannot allocate, a page order > MAX_PAGE_ORDER. The warning
>> tells that kernel user please ask for a reasonably sized memory.
>
> And if panic_on_warn is enabled, like it is in billions of Linux
> systems, and a user can trigger it, then you just rebooted the box,
> causing a DoS and a simple way to get a CVE assigned for the problem.
>
>>>> 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).
>>>
>>> I don't think it can.  Regardless, even privileged userspace shouldn't
>>> be able to crash the whole system by doing something that ought to
>>> return a harmless error.
>>
>> The issue here is that the inode.c code passes the user input len without
>> checking to page allocator code. Capping that is a minimal requirement
>> to prevent untrusted userspace input getting into trusted kernel space code
>> easily.
>
> But why would inode.c know what the page allocation max is?  We have put

kmalloc document says:

kmalloc is the normal method of allocating memory
for objects smaller than page size in the kernel.

> arbitrary bounds in other places where you can cause large allocations
> from userspace (like in usbfs), and if that's needed here, great, we can
> do that too.  But don't tie that to the mm core values as those can
> change over time.

But inode.c asks for >4MB memory.


Best Regards,
Yan, Zi

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

[syzbot]

syzbot has found a reproducer for the following issue on:

HEAD commit:    8d3ae59288f1 Linux 7.2
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13bad949580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=1d67342c314f228d
dashboard link: https://syzkaller.appspot.com/bug?extid=805630f1453e490427fa
compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1637ea25580000

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+0x2427/0x2dc0 mm/page_alloc.c:5280, CPU#2: syz-executor421/6034
Modules linked in:
CPU: 2 UID: 0 PID: 6034 Comm: syz-executor421 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+0x2427/0x2dc0 mm/page_alloc.c:5280
Code: e9 8d fb ff ff 31 d2 be 28 12 00 00 48 c7 c7 a0 74 01 8c e8 7b 95 68 ff 2e 2e 2e 31 c0 e9 02 ed ff ff c6 05 85 90 bc 0e 01 90 <0f> 0b 90 e9 6f df ff ff 48 c7 c7 80 be f3 8e 45 89 f7 44 8b 74 24
RSP: 0018:ffffc900048c7810 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 1ffff92000918f1c RDI: 0000000000040cc0
RBP: 0000000000000013 R08: 0000000000000005 R09: 0000000000000009
R10: 0000000000000013 R11: 0000000000000000 R12: 0000000000040cc0
R13: 1ffff92000918f5a R14: ffffffff9b95c444 R15: 0000000000000001
FS:  00005555738a6400(0000) GS:ffff8880d5dde000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffd5f5d6fe8 CR3: 0000000020943000 CR4: 0000000000352ef0
Call Trace:
 <TASK>
 alloc_pages_mpol+0x1fb/0x540 mm/mempolicy.c:2490
 ___kmalloc_large_node+0xe5/0x120 mm/slub.c:5274
 __kmalloc_large_node_noprof+0x1c/0x70 mm/slub.c:5305
 __do_kmalloc_node mm/slub.c:5322 [inline]
 __kmalloc_noprof+0x5a1/0x820 mm/slub.c:5359
 _kmalloc_noprof include/linux/slab.h:992 [inline]
 ep_write_iter+0x180/0xbc0 drivers/usb/gadget/legacy/inode.c:669
 new_sync_write fs/read_write.c:595 [inline]
 vfs_write+0x6ac/0x1050 fs/read_write.c:687
 ksys_write+0x12a/0x250 fs/read_write.c:739
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0x115/0x870 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f7cc18b5cb7
Code: 48 89 fa 4c 89 df e8 98 1d 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff
RSP: 002b:00007ffd5f5d76e0 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00005555738a6400 RCX: 00007f7cc18b5cb7
RDX: 000000007fffffff RSI: 0000000000000000 RDI: 0000000000000004
RBP: 00007ffd5f5d7730 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000202 R12: 00007ffd5f5d7930
R13: 00007f7cc18ea039 R14: 00007ffd5f5d7b30 R15: 0000000000000002
 </TASK>


---
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.