From: Christian Brauner <brauner@kernel.org>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
linux-unionfs@vger.kernel.org,
Alexander Viro <viro@zeniv.linux.org.uk>,
Jan Kara <jack@suse.cz>, Kees Cook <kees@kernel.org>,
Laurent Vivier <laurent@vivier.eu>,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
"Christian Brauner (Amutable)" <brauner@kernel.org>,
stable@vger.kernel.org
Subject: [PATCH 0/3] fs: don't warn when a mount is completed from another user namespace
Date: Sun, 02 Aug 2026 20:00:42 +0200 [thread overview]
Message-ID: <20260802-work-fill_super-warn-v1-0-4e987911a39a@kernel.org> (raw)
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.
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
---
Christian Brauner (3):
ovl: don't warn when the mount is completed from another user namespace
binfmt_misc: don't warn when the mount is completed from another user namespace
selftests/filesystems: test completing a context from another user namespace
fs/binfmt_misc.c | 3 +-
fs/overlayfs/super.c | 3 +-
tools/testing/selftests/Makefile | 1 +
.../selftests/filesystems/fscontext_ns/Makefile | 10 +
.../filesystems/fscontext_ns/fscontext_ns_test.c | 239 +++++++++++++++++++++
5 files changed, 254 insertions(+), 2 deletions(-)
---
base-commit: c679ce3be6cb63763d68ab9b5d9d73ddc0a40762
change-id: 20260802-work-fill_super-warn-a7fa82502843
next reply other threads:[~2026-08-02 18:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-02 18:00 Christian Brauner [this message]
2026-08-02 18:00 ` [PATCH 1/3] ovl: don't warn when the mount is completed from another user namespace Christian Brauner
2026-08-03 12:05 ` Jan Kara
2026-08-02 18:00 ` [PATCH 2/3] binfmt_misc: " Christian Brauner
2026-08-03 12:05 ` Jan Kara
2026-08-02 18:00 ` [PATCH 3/3] selftests/filesystems: test completing a context " Christian Brauner
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=20260802-work-fill_super-warn-v1-0-4e987911a39a@kernel.org \
--to=brauner@kernel.org \
--cc=amir73il@gmail.com \
--cc=jack@suse.cz \
--cc=kees@kernel.org \
--cc=laurent@vivier.eu \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=stable@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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