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 5D171C52D6D for ; Sat, 3 Aug 2024 06:29:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 767F66B007B; Sat, 3 Aug 2024 02:29:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 717F66B0083; Sat, 3 Aug 2024 02:29:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5DF8A6B0085; Sat, 3 Aug 2024 02:29:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 3AD3F6B007B for ; Sat, 3 Aug 2024 02:29:35 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id DE440A8232 for ; Sat, 3 Aug 2024 06:29:34 +0000 (UTC) X-FDA: 82409957868.24.9E8C9F9 Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) by imf09.hostedemail.com (Postfix) with ESMTP id 121C014000A for ; Sat, 3 Aug 2024 06:29:31 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="GBehuuw/"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf09.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.218.52 as permitted sender) smtp.mailfrom=mjguzik@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722666566; a=rsa-sha256; cv=none; b=SP7YlDsJSjdWdJsu56OVueO+d5l8UCm4CnuW9VXWLykYbFE8OU8yLDRHtzxWTR89ymuu06 VfryOJ1FWxuqL+fqtcnb8bWbtun8rBlukAvgKTJdtB3oI43NZOhLtt7WrO4up0/TWe++C3 nH1UqUnN30upxfxZm95Vi3burDslRMA= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="GBehuuw/"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf09.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.218.52 as permitted sender) smtp.mailfrom=mjguzik@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722666566; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=nVBdH8r6aqubFTzoKQwMuGbkV/3y3tWnewU/Nufy8x4=; b=LOXCrl7TM32M/+p2z5+CVRixS1MSvxxFsr2tOe/mpl500VbtsyHKnVQ44S538geyru6/LS I0zqAJYTxZZFaFKt235g7ew8HbWH9GHKXlaALaMsdvvG265B0ljCZ+4JV1L13hr2DWEczO QNRAvGWC50fwruhKecshKMC/ZrKeOzg= Received: by mail-ej1-f52.google.com with SMTP id a640c23a62f3a-a7aac70e30dso229732066b.1 for ; Fri, 02 Aug 2024 23:29:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722666570; x=1723271370; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=nVBdH8r6aqubFTzoKQwMuGbkV/3y3tWnewU/Nufy8x4=; b=GBehuuw/9mj9txKL4PlW8rh5VC7c3drfcmZaK87h0R/yAcZVx5S9vRVd4z8R3qAUNI PeIeITE0N2WEPwIvvI+WsejagMuT69BGLOLcCtwEh5il2z6Rp5SKsZoEHsY1IYKMs7Io NbvdItM1r8tE6IsU9+KH8BnI6tMye2TJRJesOk+ygM3ACp7MeLb6ojRmgR9Q2OW4STFx dCujKu5pDxGBUcJjLNhBLBIglgAVwhd1AMAkmHYe93eQVVhc3GzIDWH4jldXNYYikdSE PuM0HeKBWIf7Mh4i+e1Bvv5ag3tRHIdaTNR62zFOH1U1xQCUeIZpi1CyFy2yxy6DEKSb sg5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722666570; x=1723271370; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=nVBdH8r6aqubFTzoKQwMuGbkV/3y3tWnewU/Nufy8x4=; b=OaY9E9wTvrLK7OLmBwqD5baoCmPrYn2dpuD4QlLNAwmPtdSh6TJTFyRH8vFYArDZeF hmj+BsVjwTx5/BtUvS8cq+hEVfB9fPULDzz7moxr68d2VRlQj2TVC+HTlAH2WhC/HT7z euy5SCpE/dq1jzKo6y0eH+WuBYEE/lIr8NjYxVHUNM4g13fwyEFuqKRgAen/r+gN4AJT PnqvEfyBdl6Luwp4b/y9/MAdPsBf2S5LRZOgyNfIh+LlfjJxP/m/ambivUS4ARdLW08e XwELz2seS6BvuBXK6lNrnkRn0ioXwPHG8V/tAxeGa90GlklFtiFB6fA4WKtsTzHN303t PejQ== X-Forwarded-Encrypted: i=1; AJvYcCXDxxewEygHifyxvLm7NREluFli3bcH6Tc5Y2li+g8ZhXH9QmWW5gfWCea+5UPXu6apdf8to+eWkVNyso54prYSOqw= X-Gm-Message-State: AOJu0YwIqprV5yaioD2BLiP8sGW5vr5HMTy2rWL0a0gvl9i2xl1G2yyh F7HVWtX5PAGHRQns6rhTOiOcf3oiiderwg9oy3t/A07crOiVzsZ5PTQmEHrigQEyfonZ6aYJq5M DVG6rfmONceq/zSSDKcv6QgQBzm8= X-Google-Smtp-Source: AGHT+IFmv325o1+pgG/LjanSxWspk+B4AEBtVNp6UMyei/yaP0MexaEA26gqUc76kG3b6fX8prmKolVJsjEUpXwOdbA= X-Received: by 2002:a17:907:2daa:b0:a7a:ab1a:2d71 with SMTP id a640c23a62f3a-a7dc51bd5cbmr396948866b.59.1722666570094; Fri, 02 Aug 2024 23:29:30 -0700 (PDT) MIME-Version: 1.0 References: <20240801120745.13318-1-wojciech.gladysz@infogain.com> <20240801140739.GA4186762@perftesting> <20240802155859.GB6306@perftesting> In-Reply-To: <20240802155859.GB6306@perftesting> From: Mateusz Guzik Date: Sat, 3 Aug 2024 08:29:17 +0200 Message-ID: Subject: Re: [PATCH] kernel/fs: last check for exec credentials on NOEXEC mount To: Josef Bacik Cc: =?UTF-8?Q?Wojciech_G=C5=82adysz?= , viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz, ebiederm@xmission.com, kees@kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: 121C014000A X-Rspamd-Server: rspam01 X-Stat-Signature: dxuq6o4jmu5ya879yax7uxkttwmrfehx X-HE-Tag: 1722666571-735122 X-HE-Meta: U2FsdGVkX18tDlHy006SOvhgEIKjnQJre2SbVU24QzpyMzlMdEVQ/yLqVCZrj905vMMg1qoDT2sGavz4OiO/ie1feIJeShJLGulpGNsnC3YEtyFYXIz9oQ7NEBF7em/faks8gGrupl1Hzl1NkkqjOHTdqj5ytt3JAvxVRXHoiH8eF5RoxL5sHvfgMdTZRZ3yC+uG/gs5S1Qr13XKFkY23Y2fIf/YCASvTLLezqQKuPdWztuf+7liRyfcpWuH/2cGaB8GZUDJr+TMnn0r4g39w7oge6WUDUp5biAeRclHjJTHLL8biIb+AkJHBvkGviaVsVnYU34kispu9EUrZwEyTBSuucteRdwR+SLokrzBlUYcjA4nO38gYULYAIWtZCYvS2ZRpfHepBoLef0Cp+vqPhLtOpqD2LqhaBEdKNg/hlpg42uho2eiDifbpA1YzE8DqBZU01FFwq0HnRZZF6NA4UaN8ZqopunWHiNgZagP2rS9c5VPmG+0c7yA1a/qUedIu3spAtSPpC2GxShUN52X5F+HcUaLmnMgXkP7Yh6GZ2bQyzgH8mgHex9T6JZlHP7253L4huQ0kQjf+KZikSHqJ0bF/g/szQXjMwy2gP4z+Pp8h27sohVCEsw5LloSieUiGDvLwxz3T4Z37wyXMlSiBebL1YaVaNbvOEFFLi4nWP/Lhpyi1YHaIdjJe1X6VOSkcnVEB7PtQvK7+K3LYu3pBmFThw10OVFhaIpaQGrkoQ2g6ka57NbFv3BLGIu/cLJXqCcPLW0zMy7xehobgavyA5ePirhqG3uxq9VDQzJoffQ+JSGsZzGk4TAZJ5GdNw8MwyFRiokriI+rXeUjKmlxFDM9C7DM+lZhKMoZvW4B2HL1+BO8a9TiD4q3WVLbVqZp5Viebh6V9GfX8iBie7Oos0/9upwcDuI+k96c76SD4cHxCaXHZJPpXteDIB5P6zhDyXRJLYeVKpyVw/CoAeL 9uNsgOEL WYf9aa2YXb19XfQPgRAARFIc5yq/q8btf5ARf1KlOuXUquD26SZFIb8iw9YLo6HVX+BZbU1x/n7Vds+r1busVH+m2A3ygPctfGUqJZS6nz6WbLFAqib/qofP4og6xaXBYs5Zn6zhjDC0VnLjThmzOidJD4mbvUix6glURBfQ+GO5LlGYtVzKy7iMMyUkArM9gHtHY9Ay5gf3A6bDleP9s2G3GQJpaVCZba1+a6xKwJw8AijQPa7ilYWowLhhzTt6NUm5+3s+FZQ/HOz7xgYV6YLlHsghIXhFnH8X8s/wZlOIon81a4PJrYb9klGfdP7l8xeFQU1ziklsRj3vdESeMFW+x/miH4mOqwVBdFnddg+uDjBTDi3dIYGoXoEgtMbgxCJOwo4KCYLoJ2GH2A7m0py1ICOXOkpRBy6PkIVt0G2T9ahBSH3TGAoAlyQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000123, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Aug 2, 2024 at 5:59=E2=80=AFPM Josef Bacik w= rote: > > On Thu, Aug 01, 2024 at 05:15:06PM +0200, Mateusz Guzik wrote: > > I'm not confident this is particularly valuable, but if it is, it > > probably should hide behind some debug flags. > > I'm still going to disagree here, putting it behind a debug flag means it= 'll > never get caught, and it obviously proved valuable because we're discussi= ng this > particular case. > > Is it racy? Yup sure. I think that your solution is the right way to fix= it, > and then we can have a > > WARN_ON(!(file->f_mode & FMODE_NO_EXEC_CHECKED)); > > or however we choose to flag the file, that way we are no longer racing w= ith the > mount flags and only validating that a check that should have already occ= urred > has in fact occurred. Thanks, > To my understanding the submitter ran into the thing tripping over the racy check, so this check did not find a real bug elsewhere in this instance. The only case that I know of where this fired and found a real problem was after ntfs constructed a bogus inode: https://lore.kernel.org/linux-fsdevel/20230818191239.3cprv2wncyyy5yxj@f/ But that is a deficiency in debug facilities in the vfs layer -- this only tripped over because syzkaller tried to exec a sufficiently bogus inode, while the vfs layer should have prevented that from happening to begin with. There should be well-defined spot where the filesystem claims the inode in fully constructed at which the vfs layer verifies its state (thus in particular i_mode). If implemented it would have caught the problem before the inode escaped ntfs and presumably would find some other problems which the kernel as is does not correctly report. This in part depends on someone(tm) implementing VFS_* debug macros first, preferably in a way which can dump inode info on assertion failure. I have this at the bottom on a TODO list for a rainy day. However, it's not my call to make as to what to do here. I outlined my $0,04 and I'm buggering off. --=20 Mateusz Guzik