[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m1d373iail.fsf@fess.ebiederm.org>
Date: Thu, 19 Apr 2012 16:09:54 -0700
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Marcus Meissner <meissner@...e.de>, OSS Security List <oss-security@...ts.openwall.com>, security@...nel.org, Sukadev Bhattiprolu <sukadev@...ibm.com>, Serge Hallyn <serge.hallyn@...onical.com>, Pavel Emelyanov <xemul@...nvz.org>
Subject: Re: CVE request: pid namespace leak in kernel 3.0 and 3.1
Andrew Morton <akpm@...ux-foundation.org> writes:
> (cc's added)
>
> On Thu, 19 Apr 2012 23:48:20 +0200
> Marcus Meissner <meissner@...e.de> wrote:
>
>> Hi,
>>
>> we had a user, Vadim Ponomarev (ccrssaa at karelia.ru), report a pid
>> namespace leak caused by vsftpd.
>>
>> https://bugzilla.novell.com/show_bug.cgi?id=757783
>>
>> He provided a simple reproducer:
>>
>> #include <stdio.h>
>> #include <errno.h>
>> #include <signal.h>
>> #include <sched.h>
>> #include <linux/sched.h>
>> #include <unistd.h>
>> #include <sys/syscall.h>
>>
>> int main(int argc, char *argv[])
>> {
>> int i, ret;
>>
>> for (i = 0; i < 10000; i++) {
>>
>> if (0 == (ret = syscall(__NR_clone, CLONE_NEWPID | CLONE_NEWIPC |
>> CLONE_NEWNET | SIGCHLD, NULL)))
>> return 0;
>>
>> if (-1 == ret) {
>> perror("clone");
>> break;
>> }
>>
>> }
>> return 0;
>> }
>>
>>
>> and checking "cat /proc/slabinfo|grep pid_namespace"
>> gives 10000 more active slots after running it on 3.0.13 (+SUSE patches) and 3.1.10 (+SUSE patches).
>>
>>
>> Running this on 3.2.0 (+SUSE Patches) did not result in more slots, so it was probably
>> fixed between 3.1 and 3.2 (but someone else cross check perhaps).
>>
>> Any idea welcome on which patch fixed this, I tried 1b26c9b334044cff6d1d2698f2be41bc7d9a0864
>> but it seems not helping.
Is there a corresponding struct pid leak as well? Most references to
the pid namespace are through struct pid so that is an easy one to look
at.
The previous issue vsftp ran into was network namespaces being slow to
cleanup which is a very different issue, and I just double checked even
if network namespaces were being slow to clean up it would not affect
the pid namespace.
At the very least those pid namespaces are going to stay around until
the parent process reaps the dead children, so in the trivial test
case it may simply be that there is a difference how the slab cache is
shrunk after 10,000 pid namespaces are freed.
Eric
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
