From: Roberto Sassu <roberto.sassu@huawei.com>
To: Al Viro <viro@zeniv.linux.org.uk>, Steve French <smfrench@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
CIFS <linux-cifs@vger.kernel.org>,
"Paulo Alcantara" <pc@manguebit.com>,
Christian Brauner <christian@brauner.io>,
"Mimi Zohar" <zohar@linux.ibm.com>,
Paul Moore <paul@paul-moore.com>,
"linux-integrity@vger.kernel.org"
<linux-integrity@vger.kernel.org>,
"linux-security-module@vger.kernel.org"
<linux-security-module@vger.kernel.org>
Subject: RE: kernel crash in mknod
Date: Sun, 24 Mar 2024 16:50:24 +0000 [thread overview]
Message-ID: <3441a4a1140944f5b418b70f557bca72@huawei.com> (raw)
In-Reply-To: <20240324054636.GT538574@ZenIV>
> From: Al Viro [mailto:viro@ftp.linux.org.uk] On Behalf Of Al Viro
> Sent: Sunday, March 24, 2024 6:47 AM
> On Sun, Mar 24, 2024 at 12:00:15AM -0500, Steve French wrote:
> > Anyone else seeing this kernel crash in do_mknodat (I see it with a
> > simple "mkfifo" on smb3 mount). I started seeing this in 6.9-rc (did
> > not see it in 6.8). I did not see it with the 3/12/23 mainline
> > (early in the 6.9-rc merge Window) but I do see it in the 3/22 build
> > so it looks like the regression was introduced by:
>
> FWIW, successful ->mknod() is allowed to return 0 and unhash
> dentry, rather than bothering with lookups. So commit in question
> is bogus - lack of error does *NOT* mean that you have struct inode
> existing, let alone attached to dentry. That kind of behaviour
> used to be common for network filesystems more than just for ->mknod(),
> the theory being "if somebody wants to look at it, they can bloody
> well pay the cost of lookup after dcache miss".
>
> Said that, the language in D/f/vfs.rst is vague as hell and is very easy
> to misread in direction of "you must instantiate".
>
> Thankfully, there's no counterpart with mkdir - *there* it's not just
> possible, it's inevitable in some cases for e.g. nfs.
>
> What the hell is that hook doing in non-S_IFREG cases, anyway? Move it
> up and be done with it...
Hi Al
thanks for the patch. Indeed, it was like that before, when instead of
an LSM hook there was an IMA call.
However, I thought, since we were promoting it as an LSM hook,
we should be as generic possible, and support more usages than
what was needed for IMA.
> diff --git a/fs/namei.c b/fs/namei.c
> index ceb9ddf8dfdd..821fe0e3f171 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -4050,6 +4050,8 @@ static int do_mknodat(int dfd, struct filename *name, umode_t mode,
> case 0: case S_IFREG:
> error = vfs_create(idmap, path.dentry->d_inode,
> dentry, mode, true);
> + if (!error)
> + error = security_path_post_mknod(idmap, dentry);
Minor issue, security_path_post_mknod() does not return an error.
Also, please update the description of security_path_post_mknod() to say
that it is not going to be called for non-regular files.
Hopefully, Paul also agrees with this change.
Other than that, please add my:
Reviewed-by: Roberto Sassu <roberto.sassu@huawei.com>
Thanks
Roberto
> break;
> case S_IFCHR: case S_IFBLK:
> error = vfs_mknod(idmap, path.dentry->d_inode,
> @@ -4061,10 +4063,6 @@ static int do_mknodat(int dfd, struct filename *name, umode_t mode,
> break;
> }
>
> - if (error)
> - goto out2;
> -
> - security_path_post_mknod(idmap, dentry);
> out2:
> done_path_create(&path, dentry);
> if (retry_estale(error, lookup_flags)) {
next parent reply other threads:[~2024-03-24 16:50 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAH2r5msAVzxCUHHG8VKrMPUKQHmBpE6K9_vjhgDa1uAvwx4ppw@mail.gmail.com>
[not found] ` <20240324054636.GT538574@ZenIV>
2024-03-24 16:50 ` Roberto Sassu [this message]
2024-03-24 21:02 ` kernel crash in mknod Al Viro
2024-03-25 16:06 ` Christian Brauner
2024-03-25 17:18 ` Roberto Sassu
2024-03-26 11:40 ` Christian Brauner
2024-03-26 12:53 ` Paul Moore
2024-03-28 10:53 ` Roberto Sassu
2024-03-28 11:08 ` Christian Brauner
2024-03-28 11:24 ` Roberto Sassu
2024-03-28 12:07 ` Christian Brauner
2024-03-28 13:03 ` Paul Moore
2024-03-28 12:43 ` Paul Moore
2024-03-25 17:21 ` Paul Moore
[not found] ` <CAH2r5muL4NEwLxq_qnPOCTHunLB_vmDA-1jJ152POwBv+aTcXg@mail.gmail.com>
2024-03-25 19:54 ` Al Viro
2024-03-25 20:46 ` Al Viro
2024-03-25 20:47 ` Paulo Alcantara
2024-03-25 21:13 ` Al Viro
2024-03-25 21:31 ` Paulo Alcantara
2024-03-25 17:05 ` Paul Moore
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3441a4a1140944f5b418b70f557bca72@huawei.com \
--to=roberto.sassu@huawei.com \
--cc=christian@brauner.io \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=pc@manguebit.com \
--cc=smfrench@gmail.com \
--cc=viro@zeniv.linux.org.uk \
--cc=zohar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).