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

[Vlastimil Babka (SUSE)]

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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx> wrote:
>>>>
>>>>> On Sun, 16 Aug 2026 12:25:48 -0700 syzbot <syzbot+805630f1453e490427fa@xxxxxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxx
>>>>>>
>>>>>> 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