Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2662001pxj; Mon, 31 May 2021 07:41:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwb04s8D5xDduv5JV7wYTcHEfSqVLGsuHHBWZCB3kko+UMvP/MJml7CJNczrkXzQdxm+rfd X-Received: by 2002:a05:6e02:1093:: with SMTP id r19mr5897642ilj.132.1622472078043; Mon, 31 May 2021 07:41:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622472078; cv=none; d=google.com; s=arc-20160816; b=Z3kTr6hbQf6Nmm3YWjYgxEsdu63/aSiOo19VU+18WGqFoYp+D8NdQlFZCMxNKN5Gl9 zg6Quw1Ss1HMLVLeJfzoEjPRcqW7zB4XyoPohLa+9OYSlA/0iNMRZ5z91hUl34zFJyAO RcbjLnB+HMJKQTqEEfiqEhE23wsBPIh3I80Qj8BWq7oQz9HQwxdpe7pqbwLNCNfg86w7 qVuQ2CleUx/LQ8l6+85XMh82j0oYkN8nfBKSRXopQIQdOsXwxpTuClojJ6rUO6anWVwu ODcYF+d4WT3+oDGBXUpmbEQs+LDJ7bQPGnxj7JHpMJvkW4So0cwDS9Hx/MOtcn8CNiQl 736w== 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=GY6V0ot6ImgSp8VMXxbvFMPrzuEObyLzuUSTB/6FpqaffAavlU1LNSRt7+EWh2cwnj O7r5q8ao3MvSbR6BUGP+CsNDbH5tDe3vY76ir6drPdgOMea6sptT7G9KW4PFwrwDAbhq jBETfSpNU0Ukdo260CKcR+n5xGLC9T8azZ4kIcHPE66kY2hiZw52zhy79XZSfMG4wKZE 8Fmsl8BaohpqMhxIPa8Xm/DewB0MEtnakQ2Y6BMurKl7vWVd+OhsMoKTwe6ovH32QwO3 ICBz+TYP9AQFLpZ0+hE7N3ltxQhkyb0i+67SDodiI+iLIZcwtkJsLwRN6Bh1s6FhLy5V 5LNw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=ZdbTIEJ4; 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 l11si15520953jaj.50.2021.05.31.07.41.04; Mon, 31 May 2021 07:41:18 -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=ZdbTIEJ4; 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 S232563AbhEaOmH (ORCPT + 99 others); Mon, 31 May 2021 10:42:07 -0400 Received: from mail.kernel.org ([198.145.29.99]:60130 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232285AbhEaN5a (ORCPT ); Mon, 31 May 2021 09:57:30 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 3F5DF6192D; Mon, 31 May 2021 13:35:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1622468113; bh=jkmb25lIZCsxNDvHR/Aa6xXTz6m8W8yJHam7hbHsmkc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZdbTIEJ4jGUtjD3i23eHk1H/xMJWn88q6QdMBTbDbAd8szOP544ZHBnWgzSg/1DGX iQuA6uS70vbvf7wx2SXxGYmhdJRsJksJ/+EpObV/ZVrPyKrwAwUc5jCQUnMoEZhPQx N2SYyNIRxVJtakadsGStYzjpXX+3oN3FfFNKqDDU= 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.10 076/252] USB: usbfs: Dont WARN about excessively large memory allocations Date: Mon, 31 May 2021 15:12:21 +0200 Message-Id: <20210531130700.577469507@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210531130657.971257589@linuxfoundation.org> References: <20210531130657.971257589@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;