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

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

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@nvidia.com> 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?

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


thanks,

greg k-h