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

[Greg Kroah-Hartman]

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

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.

thanks,

greg k-h