[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+805630...@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 syzk...@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

[Andrew Morton]

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

[Zi Yan]

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;

--
Best Regards,
Yan, Zi

[Alan Stern]

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

[Zi Yan]

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?

[Alan Stern]

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