Hi all,

Today's linux-next merge of the security tree got a conflict in:

  fs/namei.c

between commit:

  449c7265d60d4 ("vfs: add O_CREAT|O_DIRECTORY to open*(2)")

from the vfs-brauner tree and commit:

  16959c469f232 ("lsm: expose mount idmaps to inode hooks")

from the security tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

diff --cc fs/namei.c
index ca4f5e3be99ac,99f894f3f7e13..0000000000000
--- a/fs/namei.c
+++ b/fs/namei.c
@@@ -4227,11 -4188,16 +4227,11 @@@ int vfs_create(struct mnt_idmap *idmap
  		return -EACCES;	/* shouldn't it be ENOSYS? */
  
  	mode = vfs_prepare_mode(idmap, dir, mode, S_IALLUGO, S_IFREG);
- 	error = security_inode_create(dir, dentry, mode);
+ 	error = security_inode_create(idmap, dir, dentry, mode);
  	if (error)
  		return error;
 -	error = try_break_deleg(dir, LEASE_BREAK_DIR_CREATE, di);
 -	if (error)
 -		return error;
 -	error = dir->i_op->create(idmap, dir, dentry, mode);
 -	if (!error)
 -		fsnotify_create(dir, dentry);
 -	return error;
 +
 +	return vfs_create_no_perm(idmap, dentry, mode, di);
  }
  EXPORT_SYMBOL(vfs_create);
  
@@@ -4368,21 -4328,7 +4368,21 @@@ static int may_o_create(struct mnt_idma
  	if (error)
  		return error;
  
 -	return security_inode_create(idmap, dir->dentry->d_inode, dentry, mode);
 +	if (create_dir)
- 		error = security_inode_mkdir(dir_inode, dentry, mode);
++		error = security_inode_mkdir(idmap, dir_inode, dentry, mode);
 +	else
- 		error = security_inode_create(dir_inode, dentry, mode);
++		error = security_inode_create(idmap, dir_inode, dentry, mode);
 +
 +	return error;
 +}
 +
 +static inline umode_t o_create_mode(struct mnt_idmap *idmap,
 +		const struct inode *dir, int open_flag, umode_t mode)
 +{
 +	if (O_IS_MKDIR(open_flag))
 +		return vfs_prepare_mode(idmap, dir, mode, S_IRWXUGO | S_ISVTX, S_IFDIR);
 +	else
 +		return vfs_prepare_mode(idmap, dir, mode, S_IALLUGO, S_IFREG);
  }
  
  /**

Hi Mark/Christian,

@Mark Wasn't aware that Christian pulled this already. There are some obvious
errors in the v5 of the O_CREAT|O_DIRECTORY that Christian also pointed out.
I messed something up during rebasing and somehow forgot to format-patch
again when sending that series out.

Anyway, finally got back from holiday and fixed everything in the v6, which
I sent yesterday. So please don't pull this just yet. I am a bit surprised,
because I hadn't gotten an explicit reviewed-by on every patch in the series.

@Christian, could you review the v6 so that we can fix this for next quickly?
It fixes the rebase issues, but there are some other small changes someone
else should also look at.

> Op 14-09-2026 13:48 CEST schreef Mark Brown <broonie@kernel.org>:
> 
>  
> Hi all,
> 
> Today's linux-next merge of the security tree got a conflict in:
> 
>   fs/namei.c
> 
> between commit:
> 
>   449c7265d60d4 ("vfs: add O_CREAT|O_DIRECTORY to open*(2)")
> 
> from the vfs-brauner tree and commit:
> 
>   16959c469f232 ("lsm: expose mount idmaps to inode hooks")
> 
> from the security tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.



> 
> diff --cc fs/namei.c
> index ca4f5e3be99ac,99f894f3f7e13..0000000000000
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@@ -4227,11 -4188,16 +4227,11 @@@ int vfs_create(struct mnt_idmap *idmap
>   		return -EACCES;	/* shouldn't it be ENOSYS? */
>   
>   	mode = vfs_prepare_mode(idmap, dir, mode, S_IALLUGO, S_IFREG);
> - 	error = security_inode_create(dir, dentry, mode);
> + 	error = security_inode_create(idmap, dir, dentry, mode);
>   	if (error)
>   		return error;
>  -	error = try_break_deleg(dir, LEASE_BREAK_DIR_CREATE, di);
>  -	if (error)
>  -		return error;
>  -	error = dir->i_op->create(idmap, dir, dentry, mode);
>  -	if (!error)
>  -		fsnotify_create(dir, dentry);
>  -	return error;
>  +
>  +	return vfs_create_no_perm(idmap, dentry, mode, di);
>   }
>   EXPORT_SYMBOL(vfs_create);
>   
> @@@ -4368,21 -4328,7 +4368,21 @@@ static int may_o_create(struct mnt_idma
>   	if (error)
>   		return error;
>   
>  -	return security_inode_create(idmap, dir->dentry->d_inode, dentry, mode);
>  +	if (create_dir)
> - 		error = security_inode_mkdir(dir_inode, dentry, mode);
> ++		error = security_inode_mkdir(idmap, dir_inode, dentry, mode);
>  +	else
> - 		error = security_inode_create(dir_inode, dentry, mode);
> ++		error = security_inode_create(idmap, dir_inode, dentry, mode);
>  +
>  +	return error;
>  +}
>  +
>  +static inline umode_t o_create_mode(struct mnt_idmap *idmap,
>  +		const struct inode *dir, int open_flag, umode_t mode)
>  +{
>  +	if (O_IS_MKDIR(open_flag))
>  +		return vfs_prepare_mode(idmap, dir, mode, S_IRWXUGO | S_ISVTX, S_IFDIR);
>  +	else
>  +		return vfs_prepare_mode(idmap, dir, mode, S_IALLUGO, S_IFREG);
>   }
>   
>   /**

OK, doesn't look too bad. It's just that the struct mnt_idmap in now being passed
around, it looks like.

Thanks,
Jori.