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

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" <[email protected]> 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?

>
>>>> Heaven knows how common panic_on_warn usage is.  Gemini tells me "There
>>>> is no exact global headcount or precise user metric for how many people
>>>> use panic_on_warn.  However, the setting is widely enabled across a few
>>>> billion Android devices and many cloud/server provider host kernels
>>>> where automated failover makes a full reboot preferable to running with
>>>> an unknown warning state".
>>>>
>>>> So I do think that WARNs are more serious than we (mm developers) tend
>>>> to assume.
>>>
>>> I do know that Greg KH has pretty strong feelings about this issue.
>>
>> But the warning here is when kernel user wants buddy allocator to give
>> what it cannot allocate, a page order > MAX_PAGE_ORDER. The warning
>> tells that kernel user please ask for a reasonably sized memory.
>
> And if panic_on_warn is enabled, like it is in billions of Linux
> systems, and a user can trigger it, then you just rebooted the box,
> causing a DoS and a simple way to get a CVE assigned for the problem.
>
>>>> So we just shouldn't permit userspace to trivially trigger a
>>>> page-allocation WARN.  Especially if the caller is perfectly capable of
>>>> handling an ENOMEM allocation failure, as appears to be the case with
>>>> usb-gadget.
>>>>
>>>> (Does usb-gadget actually get used by Android?  Surely not by cloud
>>>> providers!)
>>>>
>>>> (Can this WARN be triggered by unprivileged userspace?  I didn't look,
>>>> this matters a lot).
>>>
>>> I don't think it can.  Regardless, even privileged userspace shouldn't
>>> be able to crash the whole system by doing something that ought to
>>> return a harmless error.
>>
>> The issue here is that the inode.c code passes the user input len without
>> checking to page allocator code. Capping that is a minimal requirement
>> to prevent untrusted userspace input getting into trusted kernel space code
>> easily.
>
> But why would inode.c know what the page allocation max is?  We have put

kmalloc document says:

kmalloc is the normal method of allocating memory
for objects smaller than page size in the kernel.

> arbitrary bounds in other places where you can cause large allocations
> from userspace (like in usbfs), and if that's needed here, great, we can
> do that too.  But don't tie that to the mm core values as those can
> change over time.

But inode.c asks for >4MB memory.


Best Regards,
Yan, Zi