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 54A36EE49A5 for ; Sat, 19 Aug 2023 11:34:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A7AB7900006; Sat, 19 Aug 2023 07:34:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A04FA900004; Sat, 19 Aug 2023 07:34:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8A581900006; Sat, 19 Aug 2023 07:34:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 77BA9900004 for ; Sat, 19 Aug 2023 07:34:47 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 1851F1A07B4 for ; Sat, 19 Aug 2023 11:34:47 +0000 (UTC) X-FDA: 81140647014.11.39EAFA9 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf01.hostedemail.com (Postfix) with ESMTP id 6D3AE40012 for ; Sat, 19 Aug 2023 11:34:45 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="W/Y6OMmR"; spf=pass (imf01.hostedemail.com: domain of brauner@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=brauner@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692444885; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=xmL5t47xlsNGD0J7IBC1SIc96I2FT4e3TeVOfa9G4uM=; b=F1+PaOaqn/E3iJBR0SMY97p3SV216iIKpgJ+f7hD477hBnaXXlasR4CUywqE/IVIL1Csyr n6GmBFcqqLY+bUUbpjZmPqJ1n8fKcJlymo/TnqHMww+z9sOJgDmA/lWz903ZyCj/mFr2WA Ghj27RcT75aMmNx/SDsCOlYPR3THUfo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692444885; a=rsa-sha256; cv=none; b=Swh8MWeG34uVPMe8XF9nb9rkNjn6T4als/2MGhoXhUqCgc025vYyW4kwxUH1+gGoOmqP60 Wivh5855lg43wSAc2OpunB0cVrUc92/J/aEPmvU8aPS5j0wW2SGcIYBo3gbjK+Qc7M4pW5 X5tN/ymzyXzlI93vSCg4iArHLKHDwr8= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="W/Y6OMmR"; spf=pass (imf01.hostedemail.com: domain of brauner@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=brauner@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6A135601D6; Sat, 19 Aug 2023 11:34:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 92281C433C7; Sat, 19 Aug 2023 11:34:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1692444883; bh=z2ItxS/SqaayhDwGXDrxPezXvq3GP/mVQb6VL9p4QH8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=W/Y6OMmRzyS4tWEsZPyJFvcwqJezrNUqIZg+EX23Cg2LgrJApl9RfxivzPEVFp+tZ +QLmootmB73clf6IhAOmk1ZkeHtZ9tyoS3sgA915BWNCcpsKeL/4qbj2Of+icLorGc y8lezKCp8dqqeX2kOWS5RMX2njz0xrElMUDim39048oNlafa7MTbe/F0SwPyJC0qE1 rAM9nDH/Tk+kJG/UnNzcf59wnzZgelFTKmfMSM2HHstFXqkgU9h/PP7kTRryIGGUSQ VTAW/sXA6RwfAZFtzBe11LEnYeQRKPy/W6lJfWFxoiVIpBEaGUYlRXm05AAdvPpQNM icc7hQBb0msEA== Date: Sat, 19 Aug 2023 13:34:38 +0200 From: Christian Brauner To: Mateusz Guzik Cc: Kees Cook , "Eric W. Biederman" , syzbot , anton@tuxera.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-ntfs-dev@lists.sourceforge.net, syzkaller-bugs@googlegroups.com, viro@zeniv.linux.org.uk Subject: Re: [syzbot] [ntfs?] WARNING in do_open_execat Message-ID: <20230819-geblendet-energetisch-a90a2886216c@brauner> References: <000000000000c74d44060334d476@google.com> <87o7j471v8.fsf@email.froward.int.ebiederm.org> <202308181030.0DA3FD14@keescook> <20230818191239.3cprv2wncyyy5yxj@f> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20230818191239.3cprv2wncyyy5yxj@f> X-Stat-Signature: 7yrt11y4iz7dstsnim4q83e74kbu56eh X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 6D3AE40012 X-Rspam-User: X-HE-Tag: 1692444885-941411 X-HE-Meta: U2FsdGVkX1/Kr/cR+4jJJmTVSD7ROfTw5/EIhrDbgkKk+qvKSJMUy9butabRXhFF//pFc/tiOhaBH+KU/q5N3DgAwPeiImoXv0pzgePQyj9kFNIxvSZw5Y7F7IVUxxOlGmhlBHQu57XvgcHQqdd/cBoutxjI1ajr6WsqsTZfEllpHJegV4AXSxn7bTya7TNhvq4vDYH4OjBMVfdCbH980KTM18mH4qhrqWIhrtqphEMralVqXHT8M/A1e2tpO+LZ7pbMNIbWR4g0lnsROO9DwkUT1l3tYqpGoUKu2JRGuwhN+ebbbemeW6ClHSuFdo+tqR6tpggEKVTXycdbz62iIMiQATBwL1rOflDkkrhk74EyJI4CKJa19hCDjg/O4K3CLKKotu468cFejbe6vXYsMC3D78YEKJYHxjA89jp8o4BOB5OedtkzfHsL9i4IxCFpZZAWHrPAi6RUNMqGEErWvwabezG0GQD4trFaD7m7riUKhNB+XiaifjfxmJhmXJ413vYZr28Cjgv/MM9pLqNRIWWB0e1hgiXVQNJSBpwhNvgy0nZbMVfP3jcVh39ICmMSsvwg6MKhNBDa15F10QLAouAhrRjN1K1sSepbNv4XOevwlGFocDroJApH2BrmRL47iRybV5BmitY8ZcY0tNeQAvSbnvboAXGvzxlYfqTvsC3z6uZ3fpFf9LYlUQiyY4fNgpHOGdvT49tSkEofchYIqqGXWmqManzEyMlUXaq7oyeCfQqEmDo0QOZP4D0EreOByXIfCVXU7ToilmE6I/mw9DtJmg35vmcd8+PqtupSKuqYEISWnJuKsp7mAJutvxSXA4QBvAG4oJ3nOb4oN8SkGSPNbqwRT6RGNU//+GrbQaklRCsBCh6TSIenHJfqaR6UM5NGzJ9uUWSMJUJ19Snd5Mg0wM2soQklP+JJaf6NeS7JsAMDSXGsSD4/DWifaFZ922ivbLPI6u8kqdf6ltz ZSvMBrAx vGeszg4o7k6WfWhmSKd8GmO9rDTq98K3rB1YNtVeVid5kYuvx6kvMY2vvoQGd3Wknq5Ce9rVjs+bud0vEgjO9fDkz1GvpVa2SWQFT8kI8UD9JpeN58wyIROlbrx1pVzoQu5suKGVGO9sdVFjDJsgTAfP28hI2/e5nQkEoV+/KBKc3W3X5iEhXT6/8czJskldRu9Q1j2DYct6kH7wQHjY94+j1eqoUbFdVeaDWWIP7RUGttGuICWB4jMyTcYc/qe2p8MNbtr07lcWq3EtkE9XyinXugByiZBjfsZrzwNSqpI/0n7if6yI2brU53Em5RBj52k0xbYhcBqd3I7IzRwVdt3OFoou6OVvh/cS54vIRuH2ECxhuPQgdJ8cIiu2ZiStduPXdxVLJDj9Pj8kg4cU/0uYyHzMFiK4wN++ZD1g3lBx4vbYEgOxURZYAYJ2/CKKPb4QS9lkTYO/tlpUtgeS/NJj5dJ485S90G4UN 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 Fri, Aug 18, 2023 at 09:12:39PM +0200, Mateusz Guzik wrote: > On Fri, Aug 18, 2023 at 10:33:26AM -0700, Kees Cook wrote: > > This is a double-check I left in place, since it shouldn't have been reachable: > > > > /* > > * may_open() has already checked for this, so it should be > > * impossible to trip now. But we need to be extra cautious > > * and check again at the very end too. > > */ > > err = -EACCES; > > if (WARN_ON_ONCE(!S_ISREG(file_inode(file)->i_mode) || > > path_noexec(&file->f_path))) > > goto exit; > > > > As I mentioned in my other e-mail, the check is racy -- an unlucky > enough remounting with noexec should trip over it, and probably a chmod > too. > > However, that's not what triggers the warn in this case. > > The ntfs image used here is intentionally corrupted and the inode at > hand has a mode of 777 (as in type not specified). > > Then the type check in may_open(): > switch (inode->i_mode & S_IFMT) { > > fails to match anything. > > This debug printk: > diff --git a/fs/namei.c b/fs/namei.c > index e56ff39a79bc..05652e8a1069 100644 > --- a/fs/namei.c > +++ b/fs/namei.c > @@ -3259,6 +3259,10 @@ static int may_open(struct mnt_idmap *idmap, const struct path *path, > if ((acc_mode & MAY_EXEC) && path_noexec(path)) > return -EACCES; > break; > + default: > + /* bogus mode! */ > + printk(KERN_EMERG "got bogus mode inode!\n"); > + return -EACCES; > } > > error = inode_permission(idmap, inode, MAY_OPEN | acc_mode); > > catches it. > > All that said, I think adding a WARN_ONCE here is prudent, but I > don't know if denying literally all opts is the way to go. > > Do other filesystems have provisions to prevent inodes like this from > getting here? Bugs reported against the VFS from ntfs/ntfs3 are to be treated with extreme caution. Frankly, if it isn't reproducible without a corrupted ntfs/ntfs3 image it is to be dismissed until further notice. In this case it simply seems that ntfs is failing at ensuring that its own inodes it reads from disk have a well-defined type. If ntfs fails to validate that its own inodes it puts into the icache are correctly initialized then the vfs doesn't need to try and taper over this. If ntfs fails at that, there's no guarantee that it doesn't also fail at setting the correct i_ops for that inode. At which point we can check the type in may_open() but we already used bogus i_ops the whole time on some other inodes. We're not here to make up for silly bugs like this. That WARN belongs into ntfs not the vfs.