Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2730456pxj; Mon, 31 May 2021 09:17:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwvkrbDcq/ujZxLiHE/6TFCO+VmaC9aMtZI5pvvJJSm3prU91CCUbhfe2RfTvJ2nI6TPLz0 X-Received: by 2002:a02:908a:: with SMTP id x10mr20884409jaf.30.1622477837415; Mon, 31 May 2021 09:17:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622477837; cv=none; d=google.com; s=arc-20160816; b=ZeufT4TIdb+G9jrDLI0YrImOK7qgCna6rLmqDmyabGj+h+86mnAOcxJi03Dm4wN8aE Gphku/TgjR6GDUv/r4Aq8Jco1aqBsmMEs2MO3v/6sUYiR0jcinHDfEC+VfVz0VcJ4ype hxjK3hz9vczDHUuD/YKWEss/z3Plp6rT/dWc0kBkqTPoVSCpv4MJQ0SWnKjjRO8W1H39 7PT3dXghE0QzbrUudNau0a23vXaHxPli8VRZ69C4/28QTUWIKIfHS8R1iQQ+kS+w43LZ UQTwHpYW2kv1X1SJWUtvXMOyBPye9nafwVBFGSOm919TtSZlZaA3DxBC01/mCBAIvwQO NV8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=yFj56YOm7BJkYvWxk7K7Ca00NOtsvgttufjK/7y7f3o=; b=GlIl37ux6v9BydkK8PLk43ebHHixtldYVv9M01/cNKS+tQmfUTibnoh4JQuwl15rOR G8DqYtLeam+p+NG1fRZbYQA+Dw2ysUqvHooJl7lchArL+Y0LyNUOIDx/DAkJiK91ZL0x sPl8gtbIYfZ5h6pP4p7Odf4+vovk9V79bEGYE/j44yMBy1VIz8NRwiHeQCNS2CgHDq31 BED8JsIxn4dSe1X48W+IjsGIZ7bXIIxCJq4fT0kNPN1bmJd441mwkcQEWnc9ty4dmVue s3Wsj2iyBSXMX2dENxeF0zgj338NYUbYBXshJATbwT8iINMX+6Vr0luC9f7tz7+T/bdF PPVw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="eA0sO/Rh"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c7si14833563jap.0.2021.05.31.09.17.03; Mon, 31 May 2021 09:17:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="eA0sO/Rh"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233538AbhEaQQz (ORCPT + 99 others); Mon, 31 May 2021 12:16:55 -0400 Received: from mail.kernel.org ([198.145.29.99]:36490 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234156AbhEaOjf (ORCPT ); Mon, 31 May 2021 10:39:35 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 1624B61C60; Mon, 31 May 2021 13:52:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1622469161; bh=jkmb25lIZCsxNDvHR/Aa6xXTz6m8W8yJHam7hbHsmkc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eA0sO/RhOTk8zBmuuD/6ffdoHMpcrB86D7j8ymagY5FaQ/QgKgot3nF6a4txGko2l yYEF4aKgQqDgnjF8phvvRU0tA3/Gr/1edoFdEAJBkMj0aiJnsvk6p0obLIv5I8Me1U Bqnbg0hLvcLZegBc7RaavemRycyqm1U6Adh6wrlU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Andrew Morton , Alan Stern , syzbot+882a85c0c8ec4a3e2281@syzkaller.appspotmail.com Subject: [PATCH 5.12 091/296] USB: usbfs: Dont WARN about excessively large memory allocations Date: Mon, 31 May 2021 15:12:26 +0200 Message-Id: <20210531130706.955569422@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210531130703.762129381@linuxfoundation.org> References: <20210531130703.762129381@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Alan Stern commit 4f2629ea67e7225c3fd292c7fe4f5b3c9d6392de upstream. Syzbot found that the kernel generates a WARNing if the user tries to submit a bulk transfer through usbfs with a buffer that is way too large. This isn't a bug in the kernel; it's merely an invalid request from the user and the usbfs code does handle it correctly. In theory the same thing can happen with async transfers, or with the packet descriptor table for isochronous transfers. To prevent the MM subsystem from complaining about these bad allocation requests, add the __GFP_NOWARN flag to the kmalloc calls for these buffers. CC: Andrew Morton CC: Reported-and-tested-by: syzbot+882a85c0c8ec4a3e2281@syzkaller.appspotmail.com Signed-off-by: Alan Stern Link: https://lore.kernel.org/r/20210518201835.GA1140918@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman --- drivers/usb/core/devio.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) --- a/drivers/usb/core/devio.c +++ b/drivers/usb/core/devio.c @@ -1218,7 +1218,12 @@ static int do_proc_bulk(struct usb_dev_s ret = usbfs_increase_memory_usage(len1 + sizeof(struct urb)); if (ret) return ret; - tbuf = kmalloc(len1, GFP_KERNEL); + + /* + * len1 can be almost arbitrarily large. Don't WARN if it's + * too big, just fail the request. + */ + tbuf = kmalloc(len1, GFP_KERNEL | __GFP_NOWARN); if (!tbuf) { ret = -ENOMEM; goto done; @@ -1696,7 +1701,7 @@ static int proc_do_submiturb(struct usb_ if (num_sgs) { as->urb->sg = kmalloc_array(num_sgs, sizeof(struct scatterlist), - GFP_KERNEL); + GFP_KERNEL | __GFP_NOWARN); if (!as->urb->sg) { ret = -ENOMEM; goto error; @@ -1731,7 +1736,7 @@ static int proc_do_submiturb(struct usb_ (uurb_start - as->usbm->vm_start); } else { as->urb->transfer_buffer = kmalloc(uurb->buffer_length, - GFP_KERNEL); + GFP_KERNEL | __GFP_NOWARN); if (!as->urb->transfer_buffer) { ret = -ENOMEM; goto error;