From: Al Viro <viro@zeniv.linux.org.uk>
To: Christian Brauner <brauner@kernel.org>
Cc: linux-fsdevel@vger.kernel.org, Jan Kara <jack@suse.cz>,
Linus Torvalds <torvalds@linux-foundation.org>,
Jann Horn <jannh@google.com>,
stable@vger.kernel.org
Subject: Re: [PATCH 03/10] namespace: don't inherit MNT_UMOUNT in clone_mnt()
Date: Sun, 18 Oct 2026 05:32:45 +0100 [thread overview]
Message-ID: <20261018043245.GF3535232@ZenIV> (raw)
In-Reply-To: <20260926-work-mount-fixes-2-v1-3-f357abf3d17b@kernel.org>
On Sat, Sep 26, 2026 at 03:44:26PM +0200, Christian Brauner wrote:
> clone_mnt() copies the flags of the source and only masks
> MNT_INTERNAL_FLAGS which doesn't include MNT_UMOUNT. A mount that was
> lazily unmounted but is kept alive by a file descriptor can still be
> copied when its root is an nsfs or pidfs file because may_copy_tree()
> accepts those before checking whether the source is mounted at all:
>
> mount --bind /proc/self/ns/net /tmp/x
> exec 3< /tmp/x
> umount -l /tmp/x
> mount --bind /proc/self/fd/3 /tmp/y
>
> The mount on /tmp/y is attached to the caller's namespace with
> MNT_UMOUNT already set and every copy of it inherits the flag again.
>
> That causes a number of bugs:
[obviously]
I agree about adding it to MNT_INTERNAL_FLAGS, but I wonder if we should
ever allow to clone MNT_UMOUNT ones in the first place...
next prev parent reply other threads:[~2026-10-18 4:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-26 13:44 [PATCH 00/10] mount: a few additional bugfixes Christian Brauner
2026-09-26 13:44 ` [PATCH 01/10] namespace: reset the old parent's ->overmount in mnt_change_mountpoint() Christian Brauner
2026-09-26 13:44 ` [PATCH 02/10] statmount: read the parent of an unmounted mount under mount_lock Christian Brauner
2026-09-26 13:44 ` [PATCH 03/10] namespace: don't inherit MNT_UMOUNT in clone_mnt() Christian Brauner
2026-10-18 4:32 ` Al Viro [this message]
2026-10-18 16:29 ` Christian Brauner
2026-09-26 13:44 ` [PATCH 04/10] namespace: don't copy an unmounted mount tree Christian Brauner
2026-09-26 13:44 ` [PATCH 05/10] namespace: check the target before walking it in do_mount_setattr() Christian Brauner
2026-09-26 13:44 ` [PATCH 06/10] fs: refuse fspick() on internal superblocks Christian Brauner
2026-09-26 13:44 ` [PATCH 07/10] fs: put the old fs_struct before the old namespaces in unshare() Christian Brauner
2026-09-26 14:42 ` Bradley Morgan
2026-09-26 13:44 ` [PATCH 08/10] namespace: drop the file's reference first in dissolve_on_fput() Christian Brauner
2026-09-26 13:44 ` [PATCH 09/10] selftests/filesystems: check that an unmounted mount tree isn't walked Christian Brauner
2026-09-26 13:44 ` [PATCH 10/10] selftests/filesystems: check that a dead mount's overmount isn't followed 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=20261018043245.GF3535232@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=brauner@kernel.org \
--cc=jack@suse.cz \
--cc=jannh@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/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