oss-sec mailing list archives
Re: Re: CVE request: pid namespace leak in kernel 3.0 and 3.1
From: Marcus Meissner <meissner () suse de>
Date: Fri, 20 Apr 2012 12:02:56 +0200
On Fri, Apr 20, 2012 at 02:06:48AM -0700, Eric W. Biederman wrote:
Marcus Meissner <meissner () suse de> writes:On Fri, Apr 20, 2012 at 09:14:58AM +0400, Pavel Emelyanov wrote: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.Yes, apparently (mnt_cache jumps 2*tries).The other mnt_cache entry looks like the internal mount for the ipc mqueue superblock/namespace.I diffed slabinfo before and after approx 7500 tries on a freshly rebooted machine (3.1.10), here are the suspicious large jumps:Hmm. This smells like unreaped zombies, we will drop the mounts from at least the pid namespace in release_task -> proc_flush_task which you can't avoid if you get as far as release_task(), and release_task is the guts of the zombie reaper. If the mounts still exist the processes should still be visible in /proc. Is this really steady state data? Have the zombies really been reaped? Perhaps there is a signal deliver bug to init where it isn't noticing it has re parented children? Otherwise these numbers should change and go down as processes are reaped and we can get a clue about where the bug is by looking at what has leaked.
It seems stale ... I checked now (2 hours later) and the numbers are still in these ranges. There are no zombies of the process visible in ps, nor in "ls /proc". The testcase itself does leave zombies and have them reaped by init when it finishes apparently. systemd init is used here, but my 3.0.x machine uses goold old sysvinit, so it seems unrelated to systemd. Ciao, Marcus
Current thread:
- CVE request: pid namespace leak in kernel 3.0 and 3.1 Marcus Meissner (Apr 19)
- Re: CVE request: pid namespace leak in kernel 3.0 and 3.1 Eugene Teo (Apr 19)
- Re: CVE request: pid namespace leak in kernel 3.0 and 3.1 Eric W. Biederman (Apr 19)
- Re: CVE request: pid namespace leak in kernel 3.0 and 3.1 Eugene Teo (Apr 19)
- Re: CVE request: pid namespace leak in kernel 3.0 and 3.1 Pavel Emelyanov (Apr 19)
- Re: CVE request: pid namespace leak in kernel 3.0 and 3.1 Eric W. Biederman (Apr 20)
- Re: CVE request: pid namespace leak in kernel 3.0 and 3.1 Pavel Emelyanov (Apr 20)
- Re: CVE request: pid namespace leak in kernel 3.0 and 3.1 Eric W. Biederman (Apr 20)
- Re: CVE request: pid namespace leak in kernel 3.0 and 3.1 Eric W. Biederman (Apr 19)
- Re: Re: CVE request: pid namespace leak in kernel 3.0 and 3.1 Marcus Meissner (Apr 20)
- Re: Re: CVE request: pid namespace leak in kernel 3.0 and 3.1 Eric W. Biederman (Apr 20)
- Re: Re: CVE request: pid namespace leak in kernel 3.0 and 3.1 Marcus Meissner (Apr 20)
- Re: CVE request: pid namespace leak in kernel 3.0 and 3.1 Eugene Teo (Apr 19)
- Re: CVE request: pid namespace leak in kernel 3.0 and 3.1 Eric W. Biederman (Apr 20)
- Re: Re: CVE request: pid namespace leak in kernel 3.0 and 3.1 Marcus Meissner (Apr 22)
- Re: CVE request: pid namespace leak in kernel 3.0 and 3.1 Marcus Meissner (Apr 20)
- Re: CVE request: pid namespace leak in kernel 3.0 and 3.1 Kurt Seifried (Apr 20)
- Re: CVE request: pid namespace leak in kernel 3.0 and 3.1 Eric W. Biederman (Apr 19)