Re: CVE request: pid namespace leak in kernel 3.0 and 3.1

[ebiederm () xmission com (Eric W. Biederman)]

Andrew Morton <akpm () linux-foundation org> writes:

> (cc's added)
>
> On Thu, 19 Apr 2012 23:48:20 +0200
> Marcus Meissner <meissner () suse 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