BPF List
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Cai Xinchen" <caixinchen1@huawei.com>
Cc: bpf@vger.kernel.org, linux-security-module@vger.kernel.org,
	linux-trace-kernel@vger.kernel.org, selinux@vger.kernel.org,
	"Chuck Lever" <cel@kernel.org>,
	"Jeff Layton" <jlayton@kernel.org>,
	"Anna Schumaker" <anna@kernel.org>
Subject: Re: [PATCH v2 -next 04/18] fs: pass struct path to POSIX ACL helpers
Date: Thu, 15 Oct 2026 12:37:33 +0000	[thread overview]
Message-ID: <sashiko-outbox-172818@kernel.org> (raw)
In-Reply-To: <20261015125425.3246251-5-caixinchen1@huawei.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] fs/ecryptfs: ACL corruption via unintended idmap translation in ecryptfs_set_acl()
--

commit 3198ac18e49aeee9567bdcfb9d89fa401024d0e1
Author: Cai Xinchen <caixinchen1@huawei.com>

fs: pass struct path to POSIX ACL helpers

This commit updates the POSIX ACL helpers (vfs_set_acl, vfs_get_acl, and
vfs_remove_acl) along with the syscall helpers (do_set_acl, do_get_acl) to
take a struct path instead of a struct mnt_idmap and struct dentry. The
intent is to simplify callers by deriving the idmap and dentry directly
from the path where needed.

> diff --git a/fs/ecryptfs/inode.c b/fs/ecryptfs/inode.c
> index 8b2542c761ca9..b08eac01d32fd 100644
> --- a/fs/ecryptfs/inode.c
> +++ b/fs/ecryptfs/inode.c
[ ... ]
> @@ -1102,11 +1103,10 @@ static int ecryptfs_set_acl(const struct mnt_idmap *idmap,
>  			    int type)
>  {
>  	int rc;
> -	struct dentry *lower_dentry = ecryptfs_dentry_to_lower(dentry);
> -	struct inode *lower_inode = d_inode(lower_dentry);
> +	struct path lower_path = ecryptfs_lower_path(dentry);
> +	struct inode *lower_inode = d_inode(lower_path.dentry);
>  
> -	rc = vfs_set_acl(&nop_mnt_idmap, lower_dentry,
> -			 posix_acl_xattr_name(type), acl);
> +	rc = vfs_set_acl(&lower_path, posix_acl_xattr_name(type), acl);

[Severity: High]
Does passing lower_path to vfs_set_acl() here cause an unintended idmap
translation to already-global UIDs?

When a user sets a POSIX ACL on an ecryptfs mount sitting on top of an
idmapped mount, ecryptfs_set_acl() receives a posix_acl containing true
global kuid_t UIDs. These UIDs have already been translated from VFS-level
IDs by the outer VFS layer.

Previously, passing nop_mnt_idmap bypassed idmap translation and passed these
global IDs directly to the lower filesystem. By passing lower_path, the lower
mount's idmap is exposed to vfs_set_acl().

Could this cause vfs_set_acl() to erroneously treat the already-global
kuid_t UIDs as mount-specific VFS-level IDs and invoke
vfs_set_acl_idmapped_mnt(), mapping them a second time and corrupting the
ACL ownership IDs written to the backing filesystem?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261015125425.3246251-1-caixinchen1@huawei.com?part=4

  reply	other threads:[~2026-10-15 12:37 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-15 12:54 [PATCH v2 -next 00/18] landlock: Add READ_METADATA and WRITE_METADATA access rights Cai Xinchen
2026-10-15 12:54 ` [PATCH v2 -next 01/18] fs: pass struct path to notify_change() Cai Xinchen
2026-10-15 12:54 ` [PATCH v2 -next 02/18] LSM: pass struct path to the inode_setsecctx hook Cai Xinchen
2026-10-15 12:54 ` [PATCH v2 -next 03/18] fs: pass struct path to xattr helpers Cai Xinchen
2026-10-15 12:36   ` sashiko-bot
2026-10-15 12:54 ` [PATCH v2 -next 04/18] fs: pass struct path to POSIX ACL helpers Cai Xinchen
2026-10-15 12:37   ` sashiko-bot [this message]
2026-10-15 12:54 ` [PATCH v2 -next 05/18] LSM: pass struct path to the inode_setattr hook Cai Xinchen
2026-10-15 12:32   ` sashiko-bot
2026-10-15 12:54 ` [PATCH v2 -next 06/18] LSM: pass struct path to the inode xattr hooks Cai Xinchen
2026-10-15 12:54 ` [PATCH v2 -next 07/18] LSM: pass struct path to the inode posix acl hooks Cai Xinchen
2026-10-15 12:54 ` [PATCH v2 -next 08/18] LSM: pass struct path to the inode fileattr hooks Cai Xinchen
2026-10-15 12:54 ` [PATCH v2 -next 09/18] landlock: Add READ_METADATA and WRITE_METADATA access rights Cai Xinchen
2026-10-15 12:37   ` sashiko-bot
2026-10-15 12:54 ` [PATCH v2 -next 10/18] LSM: rename inode_getattr to path_getattr Cai Xinchen
2026-10-15 12:32   ` sashiko-bot
2026-10-15 12:54 ` [PATCH v2 -next 11/18] LSM: rename inode_setattr to path_setattr Cai Xinchen
2026-10-15 12:54 ` [PATCH v2 -next 12/18] LSM: rename the inode xattr hooks to path_xattr hooks Cai Xinchen
2026-10-15 12:54 ` [PATCH v2 -next 13/18] LSM: rename the inode posix acl hooks to path_*_acl hooks Cai Xinchen
2026-10-15 12:39   ` sashiko-bot
2026-10-15 12:54 ` [PATCH v2 -next 14/18] LSM: rename the inode fileattr hooks to path_file_* hooks Cai Xinchen
2026-10-15 12:54 ` [PATCH v2 -next 15/18] LSM: rename inode_setsecctx to path_setsecctx Cai Xinchen
2026-10-15 12:54 ` [PATCH v2 -next 16/18] selftests/landlock: Add tests for metadata access rights Cai Xinchen
2026-10-15 12:46   ` sashiko-bot
2026-10-15 12:54 ` [PATCH v2 -next 17/18] samples/landlock: Add metadata rights to sandboxer Cai Xinchen
2026-10-15 12:54 ` [PATCH v2 -next 18/18] Documentation: Update landlock doc for metadata rights Cai Xinchen
2026-10-15 12:39   ` sashiko-bot

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=sashiko-outbox-172818@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=anna@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=caixinchen1@huawei.com \
    --cc=cel@kernel.org \
    --cc=jlayton@kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=selinux@vger.kernel.org \
    /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