From: Paul Menage <menage@google.com>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Li Zefan <lizf@cn.fujitsu.com>,
Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
Linux Containers <containers@lists.linux-foundation.org>
Subject: Re: [PATCH] cgroups: fix possible use after free
Date: Tue, 10 Feb 2009 16:01:07 -0800 [thread overview]
Message-ID: <6599ad830902101601i294ffaa5xd01611c5121a5685@mail.gmail.com> (raw)
In-Reply-To: <20090210124527.GA28946@ZenIV.linux.org.uk>
On Tue, Feb 10, 2009 at 4:45 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Tue, Feb 10, 2009 at 02:15:36AM -0800, Paul Menage wrote:
>> On Tue, Feb 10, 2009 at 1:31 AM, Li Zefan <lizf@cn.fujitsu.com> wrote:
>> > In cgroup_kill_sb(), root is freed before sb is detached from the list,
>> > so another sget() may find this sb and call cgroup_test_super(),
>> > which will access the root that has been freed.
>>
>> I think that I'd assumed that by the time we get to cgroup_kill_sb()
>> there's no chance of the sb being resurrected by sget().
>
> There is none. grab_super() will fail to get it, so sget() will go
> through retry logics. Which doesn't mean that test won't be called
> on it in the meanwhile.
OK, so Zefan's patch looks like the safest way to fix this particular
issue. I think I see some other potential races with
cgroup_test_super() though - we probably need to synchronize against
the changing of a root's subsys_bits in rebind_subsystems(). Taking
cgroup_mutex around the call to sget() would certainly provide that,
but I'd have to check whether it causes locking cycles.
Paul
next prev parent reply other threads:[~2009-02-11 0:01 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-10 9:31 Li Zefan
2009-02-10 10:15 ` Paul Menage
2009-02-10 12:45 ` Al Viro
2009-02-11 0:01 ` Paul Menage [this message]
2009-02-11 1:19 ` Al Viro
2009-02-11 1:54 ` Paul Menage
2009-02-11 0:01 ` Paul Menage
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=6599ad830902101601i294ffaa5xd01611c5121a5685@mail.gmail.com \
--to=menage@google.com \
--cc=akpm@linux-foundation.org \
--cc=containers@lists.linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--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
all inboxes | Powered by JetHome®