From: Al Viro <viro@ZenIV.linux.org.uk>
To: Kirill Tkhai <ktkhai@virtuozzo.com>
Cc: Alexander Aring <aring@mojatatu.com>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
Jamal Hadi Salim <jhs@mojatatu.com>
Subject: Re: [bisected] Stack overflow after fs: "switch the IO-triggering parts of umount to fs_pin" (was net namespaces kernel stack overflow)
Date: Thu, 19 Apr 2018 17:44:24 +0100 [thread overview]
Message-ID: <20180419164424.GI30522@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20180419153447.GH30522@ZenIV.linux.org.uk>
On Thu, Apr 19, 2018 at 04:34:48PM +0100, Al Viro wrote:
> IOW, we only get there if our vfsmount was an MNT_INTERNAL one.
> So we have mnt->mnt_umount of some MNT_INTERNAL mount found in
> ->mnt_pins of some other mount. Which, AFAICS, means that
> it used to be mounted on that other mount. How the hell can
> that happen?
>
> It looks like you somehow get a long chain of MNT_INTERNAL mounts
> stacked on top of each other, which ought to be prevented by
> mnt_flags &= ~MNT_INTERNAL_FLAGS;
> in do_add_mount(). Nuts...
Arrrrrgh... Nuts is right - clone_mnt() preserves the sodding
MNT_INTERNAL, with obvious results.
netns is related to the problem, by exposing MNT_INTERNAL mounts
(in /proc/*/ns/*) for mount --bind to copy and attach to the
tree. AFAICS, the minimal reproducer is
touch /tmp/a
unshare -m sh -c 'for i in `seq 10000`; do mount --bind /proc/1/ns/net /tmp/a; done'
(and it can be anything in /proc/*/ns/*, really)
I think the fix should be along the lines of the following:
Don't leak MNT_INTERNAL away from internal mounts
We want it only for the stuff created by SB_KERNMOUNT mounts, *not* for
their copies.
Cc: stable@kernel.org
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
diff --git a/fs/namespace.c b/fs/namespace.c
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -1089,7 +1089,8 @@ static struct mount *clone_mnt(struct mount *old, struct dentry *root,
goto out_free;
}
- mnt->mnt.mnt_flags = old->mnt.mnt_flags & ~(MNT_WRITE_HOLD|MNT_MARKED);
+ mnt->mnt.mnt_flags = old->mnt.mnt_flags;
+ mnt->mnt.mnt_flags &= ~(MNT_WRITE_HOLD|MNT_MARKED|MNT_INTERNAL);
/* Don't allow unprivileged users to change mount flags */
if (flag & CL_UNPRIVILEGED) {
mnt->mnt.mnt_flags |= MNT_LOCK_ATIME;
next prev parent reply other threads:[~2018-04-19 16:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-18 19:45 net namespaces kernel stack overflow Alexander Aring
2018-04-18 22:08 ` Kirill Tkhai
2018-04-19 12:50 ` [bisected] Stack overflow after fs: "switch the IO-triggering parts of umount to fs_pin" (was net namespaces kernel stack overflow) Kirill Tkhai
2018-04-19 15:34 ` Al Viro
2018-04-19 16:44 ` Al Viro [this message]
2018-04-19 16:56 ` Kirill Tkhai
2018-04-19 18:37 ` Alexander Aring
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=20180419164424.GI30522@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=aring@mojatatu.com \
--cc=jhs@mojatatu.com \
--cc=ktkhai@virtuozzo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.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 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.