Linux USB
 help / color / mirror / Atom feed
From: "Vlastimil Babka (SUSE)" <vbabka@kernel.org>
To: Zi Yan <ziy@nvidia.com>,
	David Laight <david.laight.linux@gmail.com>,
	Harry Yoo <harry@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	syzbot <syzbot+805630f1453e490427fa@syzkaller.appspotmail.com>,
	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: Wed, 26 Aug 2026 12:26:10 +0200	[thread overview]
Message-ID: <733d4be4-2983-4591-9769-e2ccd64191d6@kernel.org> (raw)
In-Reply-To: <BA5425C6-1906-4938-AE75-93719AAFA45D@nvidia.com>

On 8/21/26 17:31, Zi Yan wrote:
> On 21 Aug 2026, at 11:13, David Laight wrote:
> 
>> On Fri, 21 Aug 2026 10:24:36 -0400
>> "Zi Yan" <ziy@nvidia.com> wrote:
>>
>>> On Fri Aug 21, 2026 at 4:30 AM EDT, David Laight wrote:
>>>> On Sun, 16 Aug 2026 13:52:01 -0700
>>>> Andrew Morton <akpm@linux-foundation.org> 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.
>>>>
>>>> Should there be a separate flags for 'request too large' and
>>>> 'no memory available' ?
>>>
>>> What flags? Are you suggesting kmalloc should return an ERR_PTR to
>>> distinguish different error types?
>>
>> That would break to much...
> 
> +Vlastimil and Harry on this. Maybe worth giving it a try.

We would have to change every existing caller to check for ERR_PTR instead
of just NULL check? Not worth it IMHO.

>> I was thinking of a GFP_NOWARN_TOOBIG.
>>
>> That isn't enough to change the errno though.
>> But a smaller sanity limit may make sense anyway.
> 
> Maybe. I am not sure if we want to spend a GFP flag for that.

Agreed, those are scarce and this is not worth it either.

Maybe a wrapper for kmalloc() for "allocations with potentially untrusted
unsanitized size" could be made (we can always increase the existing wrapper
hell...).

> Best Regards,
> Yan, Zi


  reply	other threads:[~2026-08-26 10:26 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
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) [this message]
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=733d4be4-2983-4591-9769-e2ccd64191d6@kernel.org \
    --to=vbabka@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=apopple@nvidia.com \
    --cc=byungchul@sk.com \
    --cc=david.laight.linux@gmail.com \
    --cc=david@kernel.org \
    --cc=gourry@gourry.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=harry@kernel.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=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