summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/stackcollapse.py
diff options
context:
space:
mode:
authorChristian Brauner <brauner@kernel.org>2026-08-10 09:36:06 +0200
committerChristian Brauner <brauner@kernel.org>2026-08-10 09:36:06 +0200
commit86bcfe2e37cee93bb495ecd3238116ffd21183e9 (patch)
tree15e7026ec194c341c3c376a85601ff4690e77bda /tools/perf/scripts/python/stackcollapse.py
parentdb2ddb87143519e20a95aa36c60b36107b736a58 (diff)
parentd64ba78b749ad6bae0e9a6f40614eda1c7db2f04 (diff)
Merge patch series "fs: don't warn when a mount is completed from another user namespace"
Christian Brauner <brauner@kernel.org> says: fsopen() records the caller's user namespace in fc->user_ns and hands back an ordinary file descriptor. The task that calls fsconfig(CMD_CREATE) doesn't have to be the one that created the context, and mount_capable() lets it through as long as the caller has CAP_SYS_ADMIN over fc->user_ns, which anyone in an ancestor namespace does. So fc->user_ns != current_user_ns() is something an unprivileged user can arrange. Both overlayfs and binfmt_misc WARN_ON() that. They're plain WARN_ON()s, so it can be done in a loop to taint the kernel and flood the log, and it panics a machine booted with panic_on_warn. Keep refusing the mount, just stop warning about it. Overlayfs already spells the same check as a plain error return in ovl_parse_param() for Opt_override_creds. And add a selftest for both cases. * patches from https://patch.msgid.link/20260802-work-fill_super-warn-v1-0-4e987911a39a@kernel.org: selftests/filesystems: test completing a context from another user namespace binfmt_misc: don't warn when the mount is completed from another user namespace ovl: don't warn when the mount is completed from another user namespace Link: https://patch.msgid.link/20260802-work-fill_super-warn-v1-0-4e987911a39a@kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Diffstat (limited to 'tools/perf/scripts/python/stackcollapse.py')
0 files changed, 0 insertions, 0 deletions