diff options
| author | Amir Goldstein <amir73il@gmail.com> | 2026-10-17 18:43:30 +0200 |
|---|---|---|
| committer | Amir Goldstein <amir73il@gmail.com> | 2026-10-29 13:24:51 +0100 |
| commit | 333ad304d4794d6384087ea7fc16e58ab642809b (patch) | |
| tree | 5c256126929f407781c3fdc91ded8a1ab02633d1 /scripts/stackusage | |
| parent | aefaf9521c999206b7cd2df8435a270ea8b8112b (diff) | |
| download | linux-333ad304d4794d6384087ea7fc16e58ab642809b.tar.gz linux-333ad304d4794d6384087ea7fc16e58ab642809b.zip | |
ovl: fix mount setup failing when override_creds drops CAP_SYS_ADMIN
When a process drops CAP_SYS_ADMIN and calls fsconfig(FSCONFIG_SET_FLAG,
"override_creds"), overlayfs saves those restricted credentials in
ofs->creator_cred. ovl_fill_super() then wraps the entire mount setup in
with_ovl_creds(), switching to those restricted credentials for the
duration.
Mount setup calls clone_private_mount(), which checks CAP_SYS_ADMIN
against current credentials. With restricted credentials active, this
check fails with -EPERM even though the task issuing
FSCONFIG_CMD_CREATE is fully privileged.
Use the mounter's real credentials only for cloning the private layer
mounts. Keep all other backing filesystem operations during mount setup
under the stashed credentials.
Reported-by: Disha Goel <disgoel@linux.ibm.com>
Closes: https://lore.kernel.org/linux-unionfs/20260924112858.51392-1-disgoel@linux.ibm.com
Fixes: c28f922c9dcee ("clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns")
Cc: stable@vger.kernel.org
Reviewed-by: Christian Brauner (Amutable) <brauner@kernel.org>
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Diffstat (limited to 'scripts/stackusage')
0 files changed, 0 insertions, 0 deletions