Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2703037pxj; Mon, 31 May 2021 08:37:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxgC4cZzRGtbnDyBn26WsUQLFSj3Ef+p/z9jrJtKqqMHXFUVk+oXB2VjU9QjvWLWDohkpuT X-Received: by 2002:a05:6602:2acc:: with SMTP id m12mr17418500iov.58.1622475471517; Mon, 31 May 2021 08:37:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622475471; cv=none; d=google.com; s=arc-20160816; b=pVJNv7bwWSnc+ktPR6YC2ZYUtxeLxQvWfqbolN/7bRp8jsBVpftTS8zWQOsaRnitm4 HS53KGX0SOURq6x9NQOOyNh8+BcGAGbmdX1cCS5QJQQ6rVUS++0XptY0W9liSEM7BrMN F38nEU+T21mTHDIGpX2f6Wz10gA1P2R5zBnsPQtHEqeLS6hOvdVSKbXlX+Z9P2HY9GzS SbHeROZ0sAw2QsVPrMeQ6lE2Vwf89tVZihVwOB6bNK+/QRGGC7jzQEptDZGYB4iZdExA Py5QyoJLRFnpN+JH0GwEZHTZloVUNlkswNZAkbzD7Ya1CVdEmJRtspdIKMD4TLpxsuHc Zv5Q== 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=oo5OjF/CJD4QApxOekFXyEZ2ssXMKGb383FUUXf8F3g=; b=nTbjDkVzdpCpDUJL1HuijziVZSW+qpCsVtG/P1X6Iqrt1m4T9CmRwWhuqOghaX0pFk Um2ZgYfOEE5N0H2lBFAh5LiDlmT1hZzK78MwpAs1iPL0R5/kS/p1MrqjOB9306G35yOq 3QaVmn2krdRPeRoeXBk3ejMjkz0JNh/bCK2JJaTMwbPw8tusijkxnBizLMlD1elDhATG 0lItSPd7ZRnuAa1/0YoXUgEY2jD11ZxetQvMNFmJBuLLwm1UBUKhLzdnO/eocFo/a6oU cNcv3HRZ8LWzWZuNWxsnJ8/5t9+FhMlAuhpjnQvl3TGSrm/kYDFv/AQX/r5+Vc+Gx8AL jDPw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Q87Z6eeF; 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 5si16495361ilx.117.2021.05.31.08.37.38; Mon, 31 May 2021 08:37:51 -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=Q87Z6eeF; 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 S233336AbhEaPhJ (ORCPT + 99 others); Mon, 31 May 2021 11:37:09 -0400 Received: from mail.kernel.org ([198.145.29.99]:48830 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233850AbhEaOVb (ORCPT ); Mon, 31 May 2021 10:21:31 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 91AF8619C5; Mon, 31 May 2021 13:44:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1622468686; bh=7xOGcdmC6Np9Qu8rfaCMEoH1HhAeG6zSr5W23vfDKsQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Q87Z6eeFPHN3P32gU2C1fxHPzqk2zd2e9mgSap5HjKxV8PlFtIhJMpunCmjHiT0Ry Pxb+UTWFnOZ6RIS6roLY6K/mWXK45IRetjyjgDRwsStIfqj/IycAg+tPWmtbk9EH4+ rkUb2Lgmr3GNvqFAEIXhzCnU7DhCMDmKcSC3bwWY= 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.4 052/177] USB: usbfs: Dont WARN about excessively large memory allocations Date: Mon, 31 May 2021 15:13:29 +0200 Message-Id: <20210531130649.724685854@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210531130647.887605866@linuxfoundation.org> References: <20210531130647.887605866@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 proc_bulk(struct usb_dev_stat 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; @@ -1691,7 +1696,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; @@ -1726,7 +1731,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;