From: Alan Stern <stern@rowland.harvard.edu>
To: Zi Yan <ziy@nvidia.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
syzbot <syzbot+805630f1453e490427fa@syzkaller.appspotmail.com>,
Vlastimil Babka <vbabka@kernel.org>,
apopple@nvidia.com, byungchul@sk.com, david@kernel.org,
gourry@gourry.net, joshua.hahnjy@gmail.com,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
matthew.brost@intel.com, rakie.kim@sk.com,
syzkaller-bugs@googlegroups.com, ying.huang@linux.alibaba.com,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-usb@vger.kernel.org
Subject: Re: [syzbot] [mm?] WARNING in ep_write_iter
Date: Thu, 20 Aug 2026 10:27:12 -0400 [thread overview]
Message-ID: <ffd191a0-17c1-4d23-a072-cdc6c9f7b4e2@rowland.harvard.edu> (raw)
In-Reply-To: <DKTTPHY9SMDO.3R1VBEGOKR95N@nvidia.com>
On Thu, Aug 20, 2026 at 09:59:27AM -0400, Zi Yan wrote:
> +Vlastimil
>
> On Thu Aug 20, 2026 at 9:55 AM EDT, 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
> >>
> >> --- 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.
> >
> > Let’s do this instead of suppressing kmalloc WARNs. Since a similar WARN[1]
> > showed up yesterday and that WARN is better handled by a bound check,
> > I do not think we want to lose the WARN from kmalloc/the page allocator.
> >
> > [1] https://lore.kernel.org/all/6a863306.ae6ddae5.3da009.0013.GAE@google.com/
Fair enough.
> > Like the patch below:
> >
> > From 732ea7074854ac3495bbceb274cdd01966118e57 Mon Sep 17 00:00:00 2001
> > From: Zi Yan <ziy@nvidia.com>
> > Date: Thu, 20 Aug 2026 09:19:12 -0400
> > Subject: [PATCH] USB: gadgetfs: do not WARN about excessively large memory
> > allocations
> >
> > GadgetFS passes an excessively large user input len to kmalloc and kmalloc
> > gives a WARN (see below for details). Suppress it by passing __GFP_NOWARN
> > to kmalloc used by both ep_write_iter() and ep_read_iter(). Follow the same
> > method as commit 4f2629ea67e72 ("USB: usbfs: Don't WARN about excessively
> > large memory allocations").
> >
> > kmalloc is used to allocate physically contiguous memory for kernel
> > allocations. For requests larger than KMALLOC_MAX_CACHE_SIZE, kmalloc uses
> > the page allocator and can only support up to KMALLOC_MAX_SIZE. For request
> > sizes bigger than KMALLOC_MAX_SIZE, the page allocator can emit a WARN
> > because kmalloc allocates an order greater than MAX_PAGE_ORDER.
> >
> > Fixes: b3c466ce5129 ("page allocator: do not sanity check order in the fast path")
> > Reported-by: syzbot+805630f1453e490427fa@syzkaller.appspotmail.com
> > Closes: https://lore.kernel.org/all/6a820ebc.9ebadd4d.20b15e.001b.GAE@google.com/
> > Tested-by: syzbot+805630f1453e490427fa@syzkaller.appspotmail.com
> > Signed-off-by: Zi Yan <ziy@nvidia.com>
> > Cc: stable@vger.kernel.org
> > ---
> > drivers/usb/gadget/legacy/inode.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/usb/gadget/legacy/inode.c b/drivers/usb/gadget/legacy/inode.c
> > index d87a8ab515107..278a0a2b39f4c 100644
> > --- a/drivers/usb/gadget/legacy/inode.c
> > +++ b/drivers/usb/gadget/legacy/inode.c
> > @@ -604,7 +604,7 @@ ep_read_iter(struct kiocb *iocb, struct iov_iter *to)
> > return -EBADMSG;
> > }
> >
> > - buf = kmalloc(len, GFP_KERNEL);
> > + buf = kmalloc(len, GFP_KERNEL | __GFP_NOWARN);
> > if (unlikely(!buf)) {
> > mutex_unlock(&epdata->lock);
> > return -ENOMEM;
> > @@ -666,7 +666,7 @@ ep_write_iter(struct kiocb *iocb, struct iov_iter *from)
> > return -EBADMSG;
> > }
> >
> > - buf = kmalloc(len, GFP_KERNEL);
> > + buf = kmalloc(len, GFP_KERNEL | __GFP_NOWARN);
> > if (unlikely(!buf)) {
> > mutex_unlock(&epdata->lock);
> > return -ENOMEM;
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Alan Stern
next prev parent reply other threads:[~2026-08-20 14:27 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <6a820ebc.9ebadd4d.20b15e.001b.GAE@google.com>
2026-08-16 20:52 ` [syzbot] [mm?] WARNING in ep_write_iter Andrew Morton
2026-08-16 21:47 ` Zi Yan
2026-08-16 23:32 ` Alan Stern
2026-08-17 0:13 ` Zi Yan
2026-08-17 1:15 ` Alan Stern
2026-08-17 1:47 ` Zi Yan
2026-08-17 2:42 ` Andrew Morton
2026-08-17 13:55 ` Alan Stern
2026-08-17 14:34 ` Zi Yan
2026-08-17 14:37 ` Zi Yan
2026-08-17 15:06 ` Alan Stern
2026-08-17 15:22 ` Zi Yan
2026-08-17 15:37 ` Alan Stern
2026-08-17 18:45 ` Zi Yan
2026-08-18 3:12 ` Alan Stern
2026-08-18 23:45 ` Zi Yan
2026-08-19 1:30 ` Alan Stern
2026-08-17 15:06 ` Greg Kroah-Hartman
2026-08-17 15:19 ` Zi Yan
2026-08-17 15:55 ` Greg Kroah-Hartman
2026-08-17 18:51 ` Zi Yan
2026-08-17 20:34 ` John Hubbard
2026-08-20 13:55 ` Zi Yan
2026-08-20 13:59 ` Zi Yan
2026-08-20 14:27 ` Alan Stern [this message]
2026-08-21 8:30 ` David Laight
2026-08-21 14:24 ` Zi Yan
2026-08-21 15:13 ` David Laight
2026-08-21 15:31 ` Zi Yan
2026-08-26 10:26 ` Vlastimil Babka (SUSE)
2026-08-17 9:14 ` syzbot
2026-08-17 19:45 ` Zi Yan
2026-08-20 13:15 ` Zi Yan
2026-08-20 13:30 ` syzbot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ffd191a0-17c1-4d23-a072-cdc6c9f7b4e2@rowland.harvard.edu \
--to=stern@rowland.harvard.edu \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=byungchul@sk.com \
--cc=david@kernel.org \
--cc=gourry@gourry.net \
--cc=gregkh@linuxfoundation.org \
--cc=joshua.hahnjy@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-usb@vger.kernel.org \
--cc=matthew.brost@intel.com \
--cc=rakie.kim@sk.com \
--cc=syzbot+805630f1453e490427fa@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=vbabka@kernel.org \
--cc=ying.huang@linux.alibaba.com \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox