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 0B085C433EF for ; Wed, 23 Mar 2022 15:43:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8BED16B0072; Wed, 23 Mar 2022 11:43:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 86C786B0073; Wed, 23 Mar 2022 11:43:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 70F976B0074; Wed, 23 Mar 2022 11:43:07 -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 620B36B0072 for ; Wed, 23 Mar 2022 11:43:07 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 2419E1F60 for ; Wed, 23 Mar 2022 15:43:07 +0000 (UTC) X-FDA: 79276069614.04.AA1A7E2 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf20.hostedemail.com (Postfix) with ESMTP id EF4331C0039 for ; Wed, 23 Mar 2022 15:43:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=WHGiwoQ7jm4I3reye7XZm6CpTzWoNyjTmyKi+u3jjKg=; b=ioGexHFlIpdyX+fUkuYz69BncV uesxLQja4XtEx1Izn4rjO4JkbJuc38YGAzFGDsK0D9mJa/KQfjONqpT0uglw4lILKXlZKtbIzIB7r XJGOEVe7glYhGDuXXiX6v+Ad0AVihbAhTphVZc+m5EQBAGUyw6WHiYRSTsewasJdsGGQV+3HLJWvN FaSGSr48Jz6TCDAD4c+E9uMZNbduvPlNkXpoQug/Lr2/BVRyWtgIMO9xaDvdY99Z2DRFC4+rX6QKS EwFj0OD0tI2S64abJRyR/Os562RgpOTr4HpNUGlpQHe0FugO1XIXnGU+o2HnpV+Wr516QZHDI6QFl l4EDk7bA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nX386-00Ce7z-WB; Wed, 23 Mar 2022 15:42:35 +0000 Date: Wed, 23 Mar 2022 15:42:34 +0000 From: Matthew Wilcox 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, linux-mm@kvack.org, linux-hardening@vger.kernel.org Subject: Re: [scsi] 6aded12b10: kernel_BUG_at_mm/usercopy.c Message-ID: 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> X-Rspam-User: X-Stat-Signature: 5ew1gd69h6adq6tidacs81fkkmcro6qw Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=ioGexHFl; spf=none (imf20.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: EF4331C0039 X-HE-Tag: 1648050185-106142 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: > On Wed, Mar 23, 2022 at 08:14:10AM +0100, Christoph Hellwig wrote: > > The actual warning is; > > > > [ 34.496096][ T331] usercopy: Kernel memory overwrite attempt detected to spans multiple pages (off set 0, size 6)! > > > > This is for the cmnd field in struct scsi_cmnd, which is allocated by > > the block layer as part of the request allocator. So with a specific > > packing it can legitimately span pages. > > > > Kees: how can we annotate that this is ok? > > The main problem is that CONFIG_HARDENED_USERCOPY_PAGESPAN=y is broken > (and nothing should be setting it). > > This series removes it: > https://lore.kernel.org/linux-hardening/20220110231530.665970-1-willy@infradead.org/ > > Matthew, what's the status of that series? Will it make the current > merge window? I thought you were going to merge it! I haven't put it in any of my public trees. > As for the SCSI changes, I'm a bit worried about type confusion, as I > don't see anything actually validating types/sizes when converting: > > static inline void *blk_mq_rq_to_pdu(struct request *rq) > { > return rq + 1; > } > > But I guess that ship has sailed. :P > > Regardless, I'm concerned that disabling PAGESPAN will just uncover > further checks, though. Where is allocation happening? The check is here: > > static int scsi_fill_sghdr_rq(struct scsi_device *sdev, struct request *rq, > struct sg_io_hdr *hdr, fmode_t mode) > { > struct scsi_cmnd *scmd = blk_mq_rq_to_pdu(rq); > > if (hdr->cmd_len < 6) > return -EMSGSIZE; > if (copy_from_user(scmd->cmnd, hdr->cmdp, hdr->cmd_len)) > return -EFAULT; > ... > } > > I don't see any earlier marking for this copy_from_user(), so I assume > the old allocation was a plain kmalloc(). > > For comparision, a related marking can be seen for a copy_to_user() case > in commit 0afe76e88c57 ("scsi: Define usercopy region in scsi_sense_cache > slab cache") > > 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? > > -- > Kees Cook >