From: Al Viro <viro@zeniv.linux.org.uk>
To: Levi <ppbuk5246@gmail.com>
Cc: davem@davemloft.net, kuba@kernel.org, gnault@redhat.com,
nicolas.dichtel@6wind.com, edumazet@google.com,
lirongqing@baidu.com, tglx@linutronix.de,
johannes.berg@intel.com, dhowells@redhat.com,
daniel@iogearbox.net, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH] netns: dangling pointer on netns bind mount point.
Date: Tue, 7 Apr 2020 04:05:04 +0100 [thread overview]
Message-ID: <20200407030504.GX23230@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20200407023512.GA25005@ubuntu>
On Tue, Apr 07, 2020 at 11:35:46AM +0900, Levi wrote:
> When we try to bind mount on network namespace (ex) /proc/{pid}/ns/net,
> inode's private data can have dangling pointer to net_namespace that was
> already freed in below case.
>
> 1. Forking the process.
> 2. [PARENT] Waiting the Child till the end.
> 3. [CHILD] call unshare for creating new network namespace
> 4. [CHILD] Bind mount with /proc/self/ns/net to some mount point.
> 5. [CHILD] Exit child.
> 6. [PARENT] Try to setns with binded mount point
>
> In step 5, net_namespace made by child process'll be freed,
> But in bind mount point, it still held the pointer to net_namespace made
> by child process.
> In this situation, when parent try to call "setns" systemcall with the
> bind mount point, parent process try to access to freed memory, That
> makes memory corruption.
>
> This patch fix the above scenario by increaseing reference count.
This can't be the right fix.
> +#ifdef CONFIG_NET_NS
> + if (!(flag & CL_COPY_MNT_NS_FILE) && is_net_ns_file(root)) {
> + ns = get_proc_ns(d_inode(root));
> + if (ns == NULL || ns->ops->type != CLONE_NEWNET) {
> + err = -EINVAL;
> +
> + goto out_free;
> + }
> +
> + net = to_net_ns(ns);
> + net = get_net(net);
No. This is completely wrong. You have each struct mount pointing to
that sucker to grab an extra reference on an object; you do *NOT* drop
said reference when struct mount is destroyed. You are papering over
a dangling pointer of some sort by introducing a trivially exploitable
leak that happens to hit your scenario.
Hell, do (your step 4 + umount your mountpoint) in a loop, then watch what
happens to refcounts with that patch.
This is bollocks; the reference is *NOT* in struct mount. At all.
It's not even in struct dentry. What it's attached to is struct
inode and it should be pinned as long as that inode is alive -
it's dropped in nsfs_evict(). And if _that_ gets called while
dentry is still pinned (as ->mnt_root of something), you have
much worse problems.
Could you post a reproducer, preferably one that would trigger an oops
on mainline?
next prev parent reply other threads:[~2020-04-07 3:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-07 2:35 [PATCH] netns: dangling pointer on netns bind mount point Levi
2020-04-07 3:05 ` Al Viro [this message]
2020-04-07 3:13 ` Al Viro
2020-04-07 3:29 ` Yun Levi
2020-04-07 4:03 ` Al Viro
[not found] ` <CAM7-yPRaQsNgZKjru40nM1N_u8HVLVKmJCAzu20DcPL=jzKjWQ@mail.gmail.com>
2020-04-07 12:57 ` Fwd: " Yun Levi
2020-04-07 18:26 ` Al Viro
2020-04-08 5:59 ` Yun Levi
2020-04-08 13:48 ` 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=20200407030504.GX23230@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=edumazet@google.com \
--cc=gnault@redhat.com \
--cc=johannes.berg@intel.com \
--cc=kuba@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lirongqing@baidu.com \
--cc=netdev@vger.kernel.org \
--cc=nicolas.dichtel@6wind.com \
--cc=ppbuk5246@gmail.com \
--cc=tglx@linutronix.de \
/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;
as well as URLs for NNTP newsgroup(s).