From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id CF05CC4332F for ; Wed, 23 Mar 2022 15:47:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 61FE46B0073; Wed, 23 Mar 2022 11:47:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5CF476B0074; Wed, 23 Mar 2022 11:47:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4BFC26B0075; Wed, 23 Mar 2022 11:47:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id 3F4646B0073 for ; Wed, 23 Mar 2022 11:47:45 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id BE0B261A4C for ; Wed, 23 Mar 2022 15:47:44 +0000 (UTC) X-FDA: 79276081290.07.73AA9F5 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf24.hostedemail.com (Postfix) with ESMTP id 43F5318003E for ; Wed, 23 Mar 2022 15:47:44 +0000 (UTC) Received: by verein.lst.de (Postfix, from userid 2407) id AA6B868B05; Wed, 23 Mar 2022 16:47:39 +0100 (CET) Date: Wed, 23 Mar 2022 16:47:39 +0100 From: Christoph Hellwig To: Kees Cook Cc: Christoph Hellwig , kernel test robot , "Martin K. Petersen" , Bart Van Assche , John Garry , LKML , lkp@lists.01.org, lkp@intel.com, "Matthew Wilcox (Oracle)" , linux-mm@kvack.org, linux-hardening@vger.kernel.org Subject: Re: [scsi] 6aded12b10: kernel_BUG_at_mm/usercopy.c Message-ID: <20220323154739.GA816@lst.de> References: <20220320143453.GD6208@xsang-OptiPlex-9020> <20220323071409.GA25480@lst.de> <202203230809.D63BF9511@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202203230809.D63BF9511@keescook> User-Agent: Mutt/1.5.17 (2007-11-01) X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: yxcu14t755ajhyhhze7m8hpqg3f8gqum Authentication-Results: imf24.hostedemail.com; dkim=none; dmarc=none; spf=none (imf24.hostedemail.com: domain of hch@lst.de has no SPF policy when checking 213.95.11.211) smtp.mailfrom=hch@lst.de X-Rspamd-Queue-Id: 43F5318003E X-HE-Tag: 1648050464-719789 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Mar 23, 2022 at 08:40:30AM -0700, Kees Cook wrote: > Regardless, I'm concerned that disabling PAGESPAN will just uncover > further checks, though. Where is allocation happening? The check is here: blk_mq_alloc_rqs, using alloc_pages_node. This hasn't actually changed with this comment. Just the size of the allocation shrunk, probably leading to the span of pages. > I *think* the allocation is happening in scsi_ioctl_reset()? But that's > a plain kmalloc(), so I'm not sure why PAGESPAN would have tripped... > are there other allocation paths? scsi_ioctl_reset is the odd one out and does also allocate a request, but that request is never used for user copies (and that whole hacky side path needs to go away, there is a huge series that needs to be finished to sort this out).