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 D7E85C433F5 for ; Wed, 23 Mar 2022 22:33:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3DF576B0072; Wed, 23 Mar 2022 18:33:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 38E2B6B0073; Wed, 23 Mar 2022 18:33:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 22F716B0074; Wed, 23 Mar 2022 18:33:33 -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 115AA6B0072 for ; Wed, 23 Mar 2022 18:33:33 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id D86141F57 for ; Wed, 23 Mar 2022 22:33:32 +0000 (UTC) X-FDA: 79277103864.14.ADD99D0 Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com [209.85.210.169]) by imf21.hostedemail.com (Postfix) with ESMTP id 510BA1C002C for ; Wed, 23 Mar 2022 22:33:32 +0000 (UTC) Received: by mail-pf1-f169.google.com with SMTP id p8so2514556pfh.8 for ; Wed, 23 Mar 2022 15:33:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=FLvEj99W00mHv5B9slSilnvGkrPhQki6M9e6QFVKTLw=; b=c+I8yLbApFcdgUn8ce7KccpjXqMKYbFfWoXTnmRsnyTyPLPllx0fX54RZjMcU+2hax 6g5G3cEOm5r3ZlMtA7kWxOLun+XwYqpPgVLElhqunddjM95buZ73WOrAkW7GhYeug88W vTT0PKJ1e5bSz1zqzS4QGFEmJq0qFDp+FbdoE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=FLvEj99W00mHv5B9slSilnvGkrPhQki6M9e6QFVKTLw=; b=LHjXJ6zjxyKXd2CmxBUm8DI09R0giwg7v1iIQoxViZY65xtLXNyf5384f5kA3CopOF Ch5Ze939Ns1GBNXT4mbyNui34y/2iW2oK3p7fsOA69G6ks5axKQxpx1zUvY+t5f6zs/+ bRwoNN0GgwQTbWIFr0K8HopCNKUROpFXzhxDrmZSwl/deQdhY7LcmMnIc3CSqAGCD2CZ k1FfHM/ZLMerCdCNKFAh1fKSPoJj7DFE0sbAq9A+goFIMAhcFeoCIQSgpGBVxVpOXsBi uk5lEqXN0yJp+v/3bGSThLsD5+EVnQGfnTj2W/WZMGhXEbeZAg+HSznjNs8SM7dcl0GX 1D1Q== X-Gm-Message-State: AOAM530hnCMjoeiw58kcTKGPBTM5rNMpugCn0XX4DvkxUYbdwywwyAUC 9rpLqaOhzZMypyl+BUjadLgYpg== X-Google-Smtp-Source: ABdhPJyz4zUzV3AWTkSwEjVMOftfaD5LbJrk0gnGi1w1o8j0flvgW2Dv6sCuVA11x5HmY4oAo0VoQw== X-Received: by 2002:a63:e243:0:b0:381:6a51:145f with SMTP id y3-20020a63e243000000b003816a51145fmr1615681pgj.625.1648074811398; Wed, 23 Mar 2022 15:33:31 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id w24-20020a639358000000b00385fcbf8e55sm708627pgm.28.2022.03.23.15.33.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Mar 2022 15:33:31 -0700 (PDT) Date: Wed, 23 Mar 2022 15:33:30 -0700 From: Kees Cook To: Christoph Hellwig Cc: 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: <202203231531.02D8297F77@keescook> References: <20220320143453.GD6208@xsang-OptiPlex-9020> <20220323071409.GA25480@lst.de> <202203230809.D63BF9511@keescook> <20220323154739.GA816@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220323154739.GA816@lst.de> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 510BA1C002C X-Stat-Signature: 5ywhsnc1bcyhmxcd3b95m978wzbhghy7 X-Rspam-User: Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=c+I8yLbA; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf21.hostedemail.com: domain of keescook@chromium.org designates 209.85.210.169 as permitted sender) smtp.mailfrom=keescook@chromium.org X-HE-Tag: 1648074812-403946 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 04:47:39PM +0100, Christoph Hellwig wrote: > 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. Okay, the page allocator _should_ be fine for that. In the mean time, lkp should probably just disable PAGESPAN. > > 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). Gotcha! -- Kees Cook