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

[Zi Yan]

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

> On Mon, Aug 17, 2026 at 11:19:23AM -0400, Zi Yan wrote:
>> 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@xxxxxxxxxx> 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?
>
> Normally this function will be making >4MB allocations, as that's what

I guess you mean “will not”.

> USB devices do.  But if a malicious userspace were to ask for more,
> well, that's what we are now discussing.
>
> This isn't the "normal" case, it's a "bad user, so what do we do to fix
> it" case.

Right. IMHO, USB code should not send unchecked user input directly to
core MM memory allocation APIs, at least the code should make sure
the user input is reasonable.

BTW, kvmalloc() also gives a WARN if the input size is bigger than INT_MAX[1][2].

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/slub.c?h=v7.2#n6912
[2] https://lore.kernel.org/all/CAHk-=wiRq+_jd_O1gz3J6-ANtXMY7iLpi8XFUcmtB3rBixvUXQ@xxxxxxxxxxxxxx/

>
> We can bound it by some magic value, or we can let the allocation fail
> like normal but just not cause a WARN message.  That's the two potential
> solutions here.

Based on my discussion with Vlastimil on IRC (he is out until next week),
I will send a patch to make kmalloc return NULL without a WARN if the request
size is bigger than KMALLOC_MAX_SIZE.



Best Regards,
Yan, Zi