linux-kernel - Re: More odd kmemleak traces.

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] [day] [month] [year] [list]

Date:	Thu, 25 Jun 2009 15:19:30 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Dave Jones <davej@...hat.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: More odd kmemleak traces.

On Wed, 2009-06-24 at 20:34 -0400, Dave Jones wrote:
> I see a bunch of kmemleak traces on one of my machines.
> These traces all seem to be early allocations during boot up,
> and I don't see anything obvious from the traces to figure out what
> we're leaking.  False positives?
> 
> Lots of these...
> 
> kmemleak: unreferenced object 0xdb9fde70 (size 40):
> kmemleak:   comm "swapper", pid 1, jiffies 4294668061
> kmemleak:   backtrace:
> kmemleak:     [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
> kmemleak:     [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
> kmemleak:     [<c066c901>] acpi_ut_allocate_object_desc_dbg+0x46/0x89
[...]

As I said in the previous e-mail, could you enable stack scanning with

echo "stack=on" > /sys/kernel/debug/kmemleak

and then cat /sys/kernel/debug/kmemleak? This should reduce the false
positives quite a lot (but with the risk of more false negatives). The
leaked objects may also be found at a subsequent scan and then kmemleak
reports "referenced object ...".

IIRC, there were some leaks in ACPI code in the past as well but the
code is too complex to be able to check whether they are real or not.

If an object is consistently reported as unreferenced in the
debug/kmemleak file, it means that it wasn't freed and it's pointer
cannot be found. The debug method I use is to try to find where the
pointer is stored in the call path and whether it is still there or not.
Usually one leak in the top part could trigger subsequent reports so
only the first ones may need to be investigated (they are always
reported in the order they were allocated).

> And a few of these in pnp..
> 
> kmemleak: unreferenced object 0xd9d0db40 (size 16):
> kmemleak:   comm "swapper", pid 1, jiffies 4294674288
> kmemleak:   backtrace:
> kmemleak:     [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
> kmemleak:     [<c04f5c89>] kmem_cache_alloc_notrace+0x121/0x13d
> kmemleak:     [<c067b9da>] reserve_range+0x4a/0x177
> kmemleak:     [<c067bba5>] system_pnp_probe+0x9e/0xcd
> kmemleak:     [<c0676c30>] pnp_device_probe+0x91/0xc1
[...]
> kmemleak: unreferenced object 0xd9d8c9a0 (size 64):
> kmemleak:   comm "swapper", pid 1, jiffies 4294674288
> kmemleak:   backtrace:
> kmemleak:     [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
> kmemleak:     [<c04f5c89>] kmem_cache_alloc_notrace+0x121/0x13d
> kmemleak:     [<c0453d29>] __request_region+0x49/0x175
> kmemleak:     [<c067ba8c>] reserve_range+0xfc/0x177
> kmemleak:     [<c067bba5>] system_pnp_probe+0x9e/0xcd
> kmemleak:     [<c0676c30>] pnp_device_probe+0x91/0xc1

Here, the first object is the kmalloc'ed regionid whose pointer is
stored in the next unreferenced object (res->name in __request_region).
So only the struct resource allocated in __request_region needs to be
investigated.

But, as above, could you try the debug/kmemleak file? It is possible
that it is just transient (if that's the case, I could enable stack
scanning by default to avoid such reports).

Thanks.

-- 
Catalin

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