linux-kernel - Re: Possible memory leak via alloc

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]

Message-ID: <20090730003658.GA27040@us.ibm.com>
Date:	Wed, 29 Jul 2009 19:36:58 -0500
From:	"Serge E. Hallyn" <serue@...ibm.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Catalin Marinas <catalin.marinas@....com>,
	linux-kernel@...r.kernel.org,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Sukadev Bhattiprolu <sukadev@...ibm.com>,
	Oleg Nesterov <oleg@...hat.com>
Subject: Re: Possible memory leak via alloc_pid()

Quoting Andrew Morton (akpm@...ux-foundation.org):
> On Wed, 8 Jul 2009 22:33:31 +0100
> Catalin Marinas <catalin.marinas@....com> wrote:
> 
> > Hi,
> > 
> > There's a kmemleak report of a struct pid allocation in alloc_pid()
> > which somehow gets lost:
> > 
> > unreferenced object 0xc307aa00 (size 44):
> >   comm "gdm", pid 2734, jiffies 4294902040
> >   backtrace:
> >     [<c01e721a>] create_object+0xfa/0x250
> >     [<c01e73cd>] kmemleak_alloc+0x5d/0x70
> >     [<c01e0ad6>] kmem_cache_alloc+0x156/0x1a0
> >     [<c01552f9>] alloc_pid+0x19/0x350
> >     [<c013e6e0>] copy_process+0x800/0x1230
> >     [<c013f17f>] do_fork+0x6f/0x370
> >     [<c0101986>] sys_clone+0x36/0x40
> >     [<c010319c>] sysenter_do_call+0x12/0x38
> >     [<ffffffff>] 0xffffffff
> > 
> > This is the gdm fork for starting Xorg (with pid 2739). It first
> > logged me in automatically, after which I logged out and gdm started
> > another Xorg. The pid structure for the first Xorg is reported as a
> > leak. The Xorg with pid 2739 is no longer present on my system.
> > 
> > Using gdb vmlinux /proc/kcore shows that the pid->count is 2, so
> > that's why it probably wasn't freed by put_pid():
> > 
> > (gdb) print ({struct pid}0xc307aa00)
> > $20 = {count = {counter = 2}, level = 0, tasks = {{first = 0x0}, {
> >       first = 0x0}, {first = 0x0}}, rcu = {next = 0xc24bfd64,
> >     func = 0xc0154e90 <delayed_put_pid>}, numbers = {{nr = 2739,
> >       ns = 0xc0737540, pid_chain = {next = 0x0, pprev = 0x200200}}}}
> > 
> > Note that kmemleak is aware of and scans pid_hash (which was recorded
> > in kmemleak as a 16KB object).
> > 
> 
> Thanks.  Let's cc some recent pid fiddlers.

Hi,

thanks for the report.  Note that kernel modules can increment those
counds through find_get_pid().  Can you send your kernel .config and
the output of lsmod?

thanks,
-serge
--
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/