linux-kernel - Re: kmemleak false positive?

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: <20090625154014.GA7866@redhat.com>
Date:	Thu, 25 Jun 2009 11:40:14 -0400
From:	Dave Jones <davej@...hat.com>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: kmemleak false positive?

On Thu, Jun 25, 2009 at 04:25:39PM +0100, Catalin Marinas wrote:
 > > Hmm, it's pretty noisy, and everything it's found so far looks to be
 > > a false positive.
 > 
 > In this case, it would make sense to enable task stacks scanning by
 > default:
 > 
 > diff --git a/mm/kmemleak.c b/mm/kmemleak.c
 > index 17096d1..a38418a 100644
 > --- a/mm/kmemleak.c
 > +++ b/mm/kmemleak.c
 > @@ -194,7 +194,7 @@ static unsigned long jiffies_min_age;
 >  /* delay between automatic memory scannings */
 >  static signed long jiffies_scan_wait;
 >  /* enables or disables the task stacks scanning */
 > -static int kmemleak_stack_scan;
 > +static int kmemleak_stack_scan = 1;

heh, I just did the same patch for the rawhide kernel builds.
 
 > >  > You can mount debugfs on /sys/kerne/debug and read the kmemleak file in
 > >  > there (it triggers a new scan as well).
 > > 
 > > Currently prints the acpi traces I already posted.
 > 
 > If they are still consistently shown with stack=on, it could be a leak.

Could be, though as you mentioned, with ACPI it's really hard to tell.

Here's another case (with stack scanning on btw) which looks odd..

 kmemleak: unreferenced object 0xd86ba000 (size 16):
 kmemleak:   comm "init", pid 1, jiffies 4294683556
 kmemleak:   backtrace:
 kmemleak:     [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
 kmemleak:     [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
 kmemleak:     [<c05cdfdc>] avtab_insertf+0xd6/0x140
 kmemleak:     [<c05ce3d7>] avtab_read_item+0x26a/0x284
 kmemleak:     [<c05ce5a5>] avtab_read+0x82/0xe5
 kmemleak:     [<c05d0618>] policydb_read+0x40c/0x1028
 kmemleak:     [<c05d459d>] security_load_policy+0x57/0x37c
 kmemleak:     [<c05c9995>] sel_write_load+0xb2/0x54a
 kmemleak:     [<c0500186>] vfs_write+0x9f/0x10f
 kmemleak:     [<c05002e1>] sys_write+0x58/0x8d
 kmemleak:     [<c040a8eb>] sysenter_do_call+0x12/0x38
 kmemleak:     [<ffffffff>] 0xffffffff

I looked over the SELinux code, and couldn't see an obvious leak.
Eric Paris came to the same conclusion.

	Dave

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