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

[Pavel Emelyanov <xemul () parallels com>]

On 04/20/2012 11:20 AM, Eric W. Biederman wrote:
> Pavel Emelyanov <xemul () parallels com> writes:
>
> > On 04/20/2012 07:10 AM, Eugene Teo wrote:
> > > > So we know what is holding the pid namespace reference.
> > > >
> > > > Additional thoughts.
> > > >
> > > > Does echo 3 > /proc/sys/vm/drop_caches clear up the issue?
> > >
> > > No.
> > >
> > > > Is there a corresponding task_struct leak?
> > >
> > > Yes.
> > >
> > > > I don't have much of a clue or much concern as this seems fixed in later kernels but I am happy to suggest things 
> > > > to look for to help narrow this down.
> > >
> > > I'm helping to provide more information.
> >
> > Is there also a vfsmount struct leak as well? The pidns creating implies
> > kern-mount-ing of a proc and it should be released when child reaper of
> > the namespace dies.
>
> In this case the user is vsftp which is an entertaining user.
>
> Roughly for every connection vsftp does:
> - accepts the connection
> - forks a server process
> - unshares the network ipc and pid namespaces for additional isolation
> - drops privilegs?
> - serves up the file.
>
> Since vsftp does not want any of the features of namespaces it does not
> setup mounts or any of that.

I'm talking about the call to pid_ns_prepare_proc which does kern_mount
thus bringing the proc sb in memory and pinning the init's pid on it.

> vsftp simply wants a way to reduce the
> the chance that a bug in the implemenation of vsftp will all the server
> to be compromised.
>
> To that extent I believe the reproduce program was very representative
> of what vsftp is doing.
>
> Eric
> .