Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932421AbcLMIEb (ORCPT ); Tue, 13 Dec 2016 03:04:31 -0500 Received: from mail-wj0-f196.google.com ([209.85.210.196]:33265 "EHLO mail-wj0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753060AbcLMIEa (ORCPT ); Tue, 13 Dec 2016 03:04:30 -0500 Date: Tue, 13 Dec 2016 09:04:26 +0100 From: Michal Hocko To: Alan Stern Cc: Andrey Konovalov , Felipe Balbi , Greg Kroah-Hartman , Al Viro , Marek Szyprowski , Deepa Dinamani , Mathieu Laurendeau , Bin Liu , USB list , LKML , syzkaller , Dmitry Vyukov , Kostya Serebryany , Cristopher Lameter Subject: Re: usb/gadget: warning in ep_write_iter/__alloc_pages_nodemask Message-ID: <20161213080426.GA10492@dhcp22.suse.cz> References: <20161212210504.GB3107@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2043 Lines: 46 On Mon 12-12-16 16:12:16, Alan Stern wrote: > On Mon, 12 Dec 2016, Michal Hocko wrote: > > > On Mon 12-12-16 21:32:35, Andrey Konovalov wrote: > > > On Mon, Dec 12, 2016 at 9:31 PM, Andrey Konovalov wrote: > > > > Hi! > > > > > > > > While running the syzkaller fuzzer I've got the following error report. > > > > > > > > The issue is that the len argument is not checked for being too big. > > > > Well, the value is checked in kmalloc_slab. There is a discrepancy > > though. While the page allocator enforces order < MAX_ORDER, slab > > allocators enforce size <= KMALLOC_MAX_SIZE and > > > > KMALLOC_MAX_SIZE is 1UL << (MAX_ORDER + PAGE_SHIFT) for SLUB which is > > what I expect you have or 1UL << (MAX_ORDER + PAGE_SHIFT - 1) for SLAB > > on most archs. This means that KMALLOC_MAX_SIZE might be MAX_ORDER for > > SLUB which would explain your warning. > > > > Let's CC Christoph, this is nothing really new, but I suspect that SLUB > > should change the maximum size to something like SLAB does. > > > > That being said, what ep_write_iter does sounds quite stupit. It just > > allocates a large continuous buffer which seems to be under user > > control... Aka no good! It should do that per pages or something like > > that. Something worth fixing > > It's not important enough to make the driver do all this work. If > users want to send large amounts of data, they can send it a page at a > time (or something like that). Is it really necessary to allocate the full iov_iter_count? Why cannot we process the from buffer one page at a time? > If you really want to prevent the driver from attempting to allocate a > large buffer, all that's needed is an upper limit on the total size. > For example, 64 KB. 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. -- Michal Hocko SUSE Labs