Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932645AbcLLVMT (ORCPT ); Mon, 12 Dec 2016 16:12:19 -0500 Received: from iolanthe.rowland.org ([192.131.102.54]:49578 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S932216AbcLLVMS (ORCPT ); Mon, 12 Dec 2016 16:12:18 -0500 Date: Mon, 12 Dec 2016 16:12:16 -0500 (EST) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Michal Hocko 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 In-Reply-To: <20161212210504.GB3107@dhcp22.suse.cz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1537 Lines: 36 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). 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. Alan Stern