linux-kernel - Re: [PATCH 2.6.18-rc4 00/10] Kernel memory leak detector 0.9

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: <1155986453.14337.9.camel@daplas.org>
Date:	Sat, 19 Aug 2006 19:20:53 +0800
From:	"Antonino A. Daplas" <adaplas@....net>
To:	Catalin Marinas <catalin.marinas@...il.com>
Cc:	Michal Piotrowski <michal.k.k.piotrowski@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2.6.18-rc4 00/10] Kernel memory leak detector 0.9

On Sat, 2006-08-19 at 11:07 +0100, Catalin Marinas wrote:
> On 18/08/06, Michal Piotrowski <michal.k.k.piotrowski@...il.com> wrote:
> > I just added your "Fix memory leak in vc_resize/vc_allocate" patch to
> > my series file.
> >
> > orphan pointer 0xc6110000 (size 12288):
> >   c017480e: <__kmalloc>
> >   c024dda4: <vc_resize>
> >   c020ed9c: <fbcon_startup>
> >   c0251028: <register_con_driver>
> >   c02511e0: <take_over_console>
> >   c020e21e: <fbcon_takeover>
> >   c0212b08: <fbcon_fb_registered>
> >   c0212ce1: <fbcon_event_notify>
> > orphan pointer 0xf55b0000 (size 8208):
> >   c017480e: <__kmalloc>
> >   c0211bb8: <fbcon_set_font>
> >   c0251b17: <con_font_set>
> >   c0251c7b: <con_font_op>
> >   c0249a97: <vt_ioctl>
> >   c024432e: <tty_ioctl>
> >   c0189fd1: <do_ioctl>
> >   c018a269: <vfs_ioctl>
> 
> The second one is probably a false positive as the stored pointer is
> different from the one returned by kmalloc (there is some padding).
> I'll add it to the kmemleak-false-positives patch.

Yes, I think it's triggered by the padding:

	new_data += FONT_EXTRA_WORDS * sizeof(int);

The free'ing in fbcon_do_set_font() takes into account the padding:

	if (old_data && (--REFCOUNT(old_data) == 0))
		kfree(old_data - FONT_EXTRA_WORDS * sizeof(int));


> The first one might be a real leak. Anotonino, any idea about this?
> 

On boot, vc->vc_screenbuf is allocated by alloc_bootmem() (vc->kmalloced
== 0), so yes, there's a leak in there . But I don't think we have a way
to deallocate this type of memory, so we just let it go. 

Tony


-
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/