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

[Zi Yan]

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.

>
>> 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.

>
>> 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.

>
>>> You can mmap a virtual address range bigger than your physical memory
>>> size plus your swap space and try to fault all pages in. That would
>>> cause OOM and the system should not crash.
>>
>> Right.  As long as it doesn't trigger a WARN!
>>
>>
>>
>>
>> Perhaps we should revisit this.
>>
>> Why are we emitting a WARN if an allocation fails, given that this will
>> often panic the kernel?  Should we on the core MM side dial that back
>> to a pr_warn() and a helpful backtrace?
>
> I think that would be a very good idea.  Only the caller knows whether
> an allocation failure will leave the system in an unstable state; the
> library routine shouldn't try to make this decision on its own.

In this case, the WARN is emitted not because of an allocation failure,
but an invalid input to buddy allocator (order > MAX_PAGE_ORDER). The
WARN is for kernel developers, telling them their code is asking too much
free memory and core MM cannot handle it. Suppressing that means
code outside MM can abuse page allocator. Code like doing
alloc_pages(MAX_PAGE_ORDER + 1, __GFP_NOFAIL | __GFP_NOWARN) should not
exist, instead of just getting pr_warn() and failures.



Best Regards,
Yan, Zi