linux-kernel - Re: [PATCH] Re: [RFC PATCH] namespaces: fix leak on fork() failure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 03 May 2012 05:12:01 +0200
From:	Mike Galbraith <efault@....de>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Oleg Nesterov <oleg@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Pavel Emelyanov <xemul@...allels.com>,
	Cyrill Gorcunov <gorcunov@...nvz.org>,
	Louis Rilling <louis.rilling@...labs.com>
Subject: Re: [PATCH]  Re: [RFC PATCH] namespaces: fix leak on fork() failure

On Tue, 2012-05-01 at 13:42 -0700, Andrew Morton wrote:
> On Tue, 01 May 2012 13:35:03 -0700
> ebiederm@...ssion.com (Eric W. Biederman) wrote:
> 
> > 
> > Andrew can you please pick up this patch?
> 
> Sure.  I assume it's fixing a post-3.4 regression?  No -stable backport
> needed?

Dunno what all should go to stable, but anyone using vsftpd will
appreciate something going.  Large leakage was initially reported
against 3.1.  That was bisected to..
423e0ab0 VFS : mount lock scalability for internal mounts 

Subsequent fixes which did not go to stable were applied..
	905ad269 procfs: fix a vfsmount longterm reference leak
	6f686574 ... and the same kind of leak for mqueue
..but leakage persists even with fork failure hole plugged.

The one (at least) that remains, grabbing pid references while we wait
for RCU destruction of pid/namespace and our subsequently never
destroying namespace is being annoying.  Yesterday I ran up >4600 leaks
with 10 background instances of the testcase (time that, egad), much
MUCH later ~4000 were released.  Between huge delay and ftrace simply
refusing to trace out of lined get_pid(), I'm having a jolly time trying
to get an 8x10 color glossy of the leaky event to stare at. 

Whatever goes to stable, what fixes this little bugger should go too.
> hm, Mike had some test code.  If that was put in
> tools/testing/selftests/nsproxy, this leak wouldn't happen again!

I didn't write it, that and a perl script to monitor leakage came along
with bug report.

-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/