Re: [PATCH v3 2/2] selinux: recheck intermediate backing files on mprotect

From: Stephen Smalley

Date: Mon Aug 31 2026 - 13:52:50 EST


On Sat, Aug 29, 2026 at 5:33 PM Karl Mehltretter <kmehltretter@xxxxxxxxx> wrote:
>
> mprotect() can be used to bypass the SELinux checks that mmap() performs
> against the intermediate layers of a stacked filesystem.
>
> mmap() checks every backing layer as the request descends through the
> stack. mprotect() only has the lowest backing file in vma->vm_file, so it
> rechecks the top-level user and the lowest mounter, but skips the mounters
> of every layer in between. With two nested overlayfs mounts and a policy
> denying mounter_t -> middle_file_t:file { execute }, a direct
> mmap(PROT_EXEC) is denied:
>
> avc: denied { execute } for pid=71 comm="nested_exec"
> path="/payload" dev="overlay" ino=9
> scontext=user_u:base_r:mounter_t
> tcontext=user_u:object_r:middle_file_t tclass=file permissive=0
>
> while mmap(PROT_NONE) followed by mprotect(PROT_EXEC) succeeds.
>
> Preserve each intermediate path, mounter SID and file-description SID in
> the backing-file security blob, copying the saved entries when another
> backing layer is opened. Allocate the array only for nested backing files,
> and release it and the path references in the backing_file_free hook.
>
> During mprotect(), recheck fd { use } and the requested inode permissions
> for every saved mounter, and include the intermediate layers in the execmod
> checks. Policy for nested stacking may then need to grant intermediate
> mounters what a direct mmap() already requires, and execmod on intermediate
> labels for binaries using text relocations.
>
> Tested on arm64 QEMU with a small BusyBox initramfs and a purpose-built
> SELinux policy, on a mainline tree containing
> commit f2381b546e7e ("fs: fix user path of nested backing files").
>
> Fixes: 82544d36b172 ("selinux: fix overlayfs mmap() and mprotect() access checks")
> Cc: <stable@xxxxxxxxxxxxxxx>
> Assisted-by: LLM
> Signed-off-by: Karl Mehltretter <kmehltretter@xxxxxxxxx>

Reviewed-by: Stephen Smalley <stephen.smalley.work@xxxxxxxxx>