Re: [PATCH v2] selinux: preserve user SID across nested backing files

From: Amir Goldstein

Date: Thu Aug 20 2026 - 15:13:41 EST


On Thu, Aug 20, 2026 at 7:58 PM Karl Mehltretter <kmehltretter@xxxxxxxxx> wrote:
>
> SELinux saves the user file SID in a backing-file security blob so it
> remains available after mmap() replaces vma->vm_file with a backing file.
>
> For nested backing files (overlayfs over overlayfs, or FUSE passthrough
> backed by overlayfs), user_file may itself be a backing file. Its
> fsec->sid is the SID of the mounter that opened it, rather than the user
> that opened the top-level file. mprotect() then checks fd { use } against
> the mounter SID. This can incorrectly deny access without a domain
> transition, or check the wrong target SID after one.
>
> Copy the saved user SID when user_file is a backing file. Keep using the
> regular file SID for the first backing layer.
>
> With two nested overlayfs mounts and SELinux enforcing,
> mprotect(PROT_READ) returns EACCES with an fd { use } denial against the
> mounter SID. With this change, mprotect() succeeds.
>
> Fixes: 82544d36b172 ("selinux: fix overlayfs mmap() and mprotect() access checks")
> Cc: stable@xxxxxxxxxxxxxxx
> Assisted-by: Codex:gpt-5.6-sol
> Signed-off-by: Karl Mehltretter <kmehltretter@xxxxxxxxx>

Reviewed-by: Amir Goldstein <amir73il@xxxxxxxxx>

> ---
> Changes in v2:
> - Add selinux_file_user_sid() helper instead of open-coding the lookup
> (Amir).
>
> Tested on arm64 QEMU at fd6e2388a3ea with SELinux enforcing and two
> nested overlayfs mounts. The policy omitted only
> base_t -> mounter_t:fd { use } among the relevant cross-domain allows:
>
> baseline: mprotect(PROT_READ) returned EACCES with that denial
> patched: mprotect(PROT_READ) succeeded; test exited 0
>
> This patch fixes SID propagation only. backing_file_user_path() still
> resolves to the middle layer for a nested mapping, so the audit path and
> inode do not correspond to uf_sid, and that layer's mounter is not
> re-checked. Preserving the full user path likely needs a VFS-side change,
> such as having backing_file_open() store file_user_path(user_file).
>
> security/selinux/hooks.c | 9 ++++++++-
> security/selinux/include/objsec.h | 2 +-
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 1ead2eee1944..171b90412ff1 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -3843,13 +3843,20 @@ static int selinux_file_alloc_security(struct file *file)
> return 0;
> }
>
> +static inline u32 selinux_file_user_sid(const struct file *file)
> +{
> + if (unlikely(file->f_mode & FMODE_BACKING))
> + return selinux_backing_file(file)->uf_sid;
> + return selinux_file(file)->sid;
> +}
> +
> static int selinux_backing_file_alloc(struct file *backing_file,
> const struct file *user_file)
> {
> struct backing_file_security_struct *bfsec;
>
> bfsec = selinux_backing_file(backing_file);
> - bfsec->uf_sid = selinux_file(user_file)->sid;
> + bfsec->uf_sid = selinux_file_user_sid(user_file);
>
> return 0;
> }
> diff --git a/security/selinux/include/objsec.h b/security/selinux/include/objsec.h
> index 3c0a16ec978b..853f7266ed18 100644
> --- a/security/selinux/include/objsec.h
> +++ b/security/selinux/include/objsec.h
> @@ -87,7 +87,7 @@ struct file_security_struct {
> };
>
> struct backing_file_security_struct {
> - u32 uf_sid; /* associated user file fsec->sid */
> + u32 uf_sid; /* top-level user file fsec->sid */
> };
>
> struct superblock_security_struct {
>
> base-commit: fd6e2388a3ea55e58cbbbef840c1d8aa2067dbb3
> --
> 2.39.5 (Apple Git-154)