Received-SPF: pass (google.com: domain of linux-kernel+bounces-112735-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
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
Thread-Topic: kernel crash in mknod
Thread-Index: AQHafag2XY/u/k17xEe65QyoT7TnEbFGUTAAgADHHcA=
Date: Sun, 24 Mar 2024 16:50:24 +0000
Message-ID: <3441a4a1140944f5b418b70f557bca72@huawei.com>
References: <CAH2r5msAVzxCUHHG8VKrMPUKQHmBpE6K9_vjhgDa1uAvwx4ppw@mail.gmail.com>
 <20240324054636.GT538574@ZenIV>
In-Reply-To: <20240324054636.GT538574@ZenIV>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
MIME-Version: 1.0

> 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:
>=20
> 	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".
>=20
> 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".
>=20
> Thankfully, there's no counterpart with mkdir - *there* it's not just
> possible, it's inevitable in some cases for e.g. nfs.
>=20
> 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 *nam=
e, umode_t mode,
>  		case 0: case S_IFREG:
>  			error =3D vfs_create(idmap, path.dentry->d_inode,
>  					   dentry, mode, true);
> +			if (!error)
> +				error =3D 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 =3D vfs_mknod(idmap, path.dentry->d_inode,
> @@ -4061,10 +4063,6 @@ static int do_mknodat(int dfd, struct filename *na=
me, umode_t mode,
>  			break;
>  	}
>=20
> -	if (error)
> -		goto out2;
> -
> -	security_path_post_mknod(idmap, dentry);
>  out2:
>  	done_path_create(&path, dentry);
>  	if (retry_estale(error, lookup_flags)) {