[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20161214161823.GQ25573@dhcp22.suse.cz>
Date: Wed, 14 Dec 2016 17:18:23 +0100
From: Michal Hocko <mhocko@...nel.org>
To: Alan Stern <stern@...land.harvard.edu>
Cc: Andrey Konovalov <andreyknvl@...gle.com>,
Felipe Balbi <balbi@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Al Viro <viro@...iv.linux.org.uk>,
Marek Szyprowski <m.szyprowski@...sung.com>,
Deepa Dinamani <deepa.kernel@...il.com>,
Mathieu Laurendeau <mat.lau@...oste.net>,
Bin Liu <b-liu@...com>, USB list <linux-usb@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
syzkaller <syzkaller@...glegroups.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
Kostya Serebryany <kcc@...gle.com>,
Cristopher Lameter <cl@...ux.com>
Subject: Re: usb/gadget: warning in ep_write_iter/__alloc_pages_nodemask
On Wed 14-12-16 11:13:11, Alan Stern wrote:
> On Wed, 14 Dec 2016, Michal Hocko wrote:
>
> > On Tue 13-12-16 08:33:34, Alan Stern wrote:
> > > On Tue, 13 Dec 2016, Michal Hocko wrote:
[...]
> > > > Well, my point was that it is not really hard to imagine to deplete
> > > > larger contiguous memory blocks (say PAGE_ALLOC_COSTLY_ORDER). Those are
> > > > still causing the OOM killer and chances are that a controlled flood of
> > > > these requests could completely DoS the system.
> > >
> > > Putting a limit on the total size of a single transfer would prevent
> > > this.
> >
> > Dunno, putting a limit to the user visible interface sounds wrong to me.
>
> In practice, I think the data transfer sizes tend to be not very large.
> But I could be wrong about that.
That is one part the other is whether a malicious user can abuse this to
DoS the kernel which is the point I am trying to make here. Depleting
non-costly high orders can be quite dangerious so allowing a free ticket
to them to arbitrary user in an arbitrary amount is definitely not good.
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists