From: Al Viro <viro@zeniv.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-fsdevel@vger.kernel.org,
Christian Brauner <christian@brauner.io>, Jan Kara <jack@suse.cz>,
"H. Peter Anvin" <hpa@zytor.com>,
Werner Almesberger <werner@almesberger.net>
Subject: Re: [RFC] pivot_root(2) races
Date: Mon, 9 Feb 2026 06:34:54 +0000 [thread overview]
Message-ID: <20260209063454.GI3183987@ZenIV> (raw)
In-Reply-To: <CAHk-=whoVEhWbBJK9SiA0XoUbyurn9gN8O0gUAne88a4gXDLyQ@mail.gmail.com>
On Sun, Feb 08, 2026 at 09:49:40PM -0800, Linus Torvalds wrote:
> On Sun, 8 Feb 2026 at 16:32, Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > AFAICS, the original rationale had been about the kernel threads
> > that would otherwise keep the old root busy.
>
> I don't think it was even about just kernel threads, it was about the
> fact that pivot_root was done early, but after other user space things
> could have been started.
>
> Of course, now it's used much more widely than the original "handle
> initial root switching in user space"
>
> > Unfortunately, the way it's been done (all the way since the
> > original posting) is racy. If pivot_root() is called while another
> > thread is in the middle of fork(), it will not see the fs_struct of
> > the child to be.
>
> I think that what is much more serious than races is the *non*racy behavior.
>
> Maybe I'm missing something, but it looks like anybody can just switch
> things around for _other_ namespaces if they have CAP_SYS_ADMIN in
> _their_ namespace. It's just using may_mount()", which i sabout the
> permission to modify the locall namespace.
>
> I probably am missing something, and just took a very quick look, and
> am missing some check for "only change processes we have permission to
> change".
Not really - look at those check_mnt() in pivot_root(2).
static inline int check_mnt(const struct mount *mnt)
{
return mnt->mnt_ns == current->nsproxy->mnt_ns;
}
SYSCALL_DEFINE2(pivot_root, const char __user *, new_root,
const char __user *, put_old)
{
...
if (!check_mnt(root_mnt) || !check_mnt(new_mnt))
return -EINVAL;
IOW, try to do that to another namespace and you'll get -EINVAL,
no matter what permissions you might have in your namespace
(or globally, for that matter).
may_mount() check is "if you don't have CAP_SYS_ADMIN in your namespace,
you are not getting anywhere at all"; check_mount() ones - "... and
it would better be your namespace you are about to change"
next prev parent reply other threads:[~2026-02-09 6:32 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-09 0:34 [RFC] pivot_root(2) races Al Viro
2026-02-09 5:49 ` Linus Torvalds
2026-02-09 5:53 ` H. Peter Anvin
2026-02-09 6:34 ` Al Viro [this message]
2026-02-09 6:44 ` Linus Torvalds
2026-02-09 11:53 ` Christian Brauner
2026-02-12 17:17 ` Askar Safin
2026-02-12 19:11 ` Linus Torvalds
2026-02-12 19:31 ` H. Peter Anvin
2026-02-13 9:51 ` Aleksa Sarai
2026-02-13 17:47 ` Askar Safin
2026-02-13 20:27 ` H. Peter Anvin
2026-02-13 20:35 ` H. Peter Anvin
2026-02-13 22:25 ` Al Viro
2026-02-13 23:00 ` H. Peter Anvin
2026-02-13 23:41 ` Al Viro
2026-02-13 23:40 ` H. Peter Anvin
2026-02-14 12:42 ` Christian Brauner
2026-02-15 0:48 ` H. Peter Anvin
2026-02-17 8:37 ` Christian Brauner
2026-02-14 16:20 ` Askar Safin
2026-02-15 0:49 ` H. Peter Anvin
2026-02-13 13:46 ` Aleksa Sarai
2026-02-13 15:03 ` H. Peter Anvin
2026-02-13 17:47 ` Linus Torvalds
2026-02-13 18:27 ` Askar Safin
2026-02-13 18:39 ` Linus Torvalds
2026-02-13 20:00 ` H. Peter Anvin
2026-02-14 15:31 ` Askar Safin
2026-02-15 0:52 ` H. Peter Anvin
2026-02-14 12:15 ` Christian Brauner
2026-02-14 16:18 ` Linus Torvalds
2026-02-14 17:40 ` Al Viro
2026-02-17 8:35 ` Christian Brauner
2026-02-13 18:42 ` H. Peter Anvin
2026-02-13 20:08 ` H. Peter Anvin
2026-02-12 19:22 ` Al Viro
2026-02-13 17:34 ` Askar Safin
2026-02-13 22:28 ` Al Viro
2026-02-14 16:16 ` Askar Safin
2026-02-12 13:23 ` Askar Safin
2026-02-12 19:25 ` Al Viro
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=20260209063454.GI3183987@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=christian@brauner.io \
--cc=hpa@zytor.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=werner@almesberger.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.