linux-kernel - Re: How to analyze kmemleak message?

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: <1235385947.14987.41.camel@pc1117.cambridge.arm.com>
Date:	Mon, 23 Feb 2009 10:45:47 +0000
From:	Catalin Marinas <catalin.marinas@....com>
To:	Pekka Enberg <penberg@...helsinki.fi>
Cc:	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	linux-kernel@...r.kernel.org
Subject: Re: How to analyze kmemleak message?

On Mon, 2009-02-23 at 11:40 +0200, Pekka Enberg wrote:
> On Mon, Feb 23, 2009 at 10:24 AM, Tetsuo Handa
> <penguin-kernel@...ove.sakura.ne.jp> wrote:
> > I got this message with linux-2.6.29-rc5-next-20090220 .

As Pekka said, they refer to the place where the object was allocated.
This object can no longer be found to be referred by other objects or
from the data section, hence it is assumed to be a leak (it could, as
well, be a false positive, transient or not). Basically, you need check
where the pointer returned by kmalloc/kmem_cache_alloc etc. should be
stored and whether it can still be referred from that place (or a
different one) later.

Kmemleak tries to avoid the reporting of transient leaks by only
reporting objects with a life time of more than 5 seconds. To make sure
the reports you got aren't transient leaks, you can read
the /sys/kernel/debug/kmemleak file a few times to see whether they
disappear.

There is a Documentation/kmemleak.txt file where you may find some
useful information.

Please note that the leaks are always reported in the order they were
allocated. You may find that some early leak triggers subsequent leaks
hence only one may need to be solved (this is because a leaked object
isn't scanned by kmemleak though it may contain pointers to other
objects - e.g. the alloc_vfsmnt leak below).

> > [   89.856902] unreferenced object 0xf7009180 (size 124):
> > [   89.857484]   comm "swapper", pid 0, jiffies 4294892306
> > [   89.857484]   backtrace:
> > [   89.857484]     [<c0230695>] create_object+0x155/0x2c0
> > [   89.857484]     [<c0230dcb>] kmemleak_alloc+0x10b/0x1b0
> > [   89.857484]     [<c0228581>] kmem_cache_alloc+0x191/0x220
> > [   89.857484]     [<c025dc23>] alloc_vfsmnt+0x23/0x170
> > [   89.857484]     [<c023b632>] vfs_kern_mount+0x52/0x230
> > [   89.857484]     [<c023ba2a>] kern_mount_data+0x1a/0x20
> > [   89.857484]     [<c126a03e>] bdev_cache_init+0x6e/0xd0
> > [   89.857484]     [<c1268ce7>] vfs_caches_init+0x77/0x90
> > [   89.857484]     [<c1237e8d>] start_kernel+0x25d/0x380
> > [   89.857484]     [<c1237092>] __init_begin+0x92/0xe0
> > [   89.857484]     [<ffffffff>] 0xffffffff
> > [   89.886404] unreferenced object 0xf700d0e0 (size 8):
> > [   89.888384]   comm "swapper", pid 0, jiffies 4294892306
> > [   89.890117]   backtrace:
> > [   89.890393]     [<c0230695>] create_object+0x155/0x2c0
> > [   89.890393]     [<c0230dcb>] kmemleak_alloc+0x10b/0x1b0
> > [   89.890393]     [<c022bb44>] __kmalloc_track_caller+0x234/0x2d0
> > [   89.890393]     [<c0200a95>] kstrdup+0x55/0xa0
> > [   89.890393]     [<c025dcf1>] alloc_vfsmnt+0xf1/0x170
> > [   89.890393]     [<c023b632>] vfs_kern_mount+0x52/0x230
> > [   89.890393]     [<c023ba2a>] kern_mount_data+0x1a/0x20
> > [   89.890393]     [<c126a03e>] bdev_cache_init+0x6e/0xd0
> > [   89.890393]     [<c1268ce7>] vfs_caches_init+0x77/0x90
> > [   89.890393]     [<c1237e8d>] start_kernel+0x25d/0x380
> > [   89.890393]     [<c1237092>] __init_begin+0x92/0xe0
> > [   89.890393]     [<ffffffff>] 0xffffffff

These are known to be leaks and I posted a patch some time ago:

http://lkml.org/lkml/2009/1/14/175

> > [   89.926356] unreferenced object 0xf60f6080 (size 16):
> > [   89.929082]   comm "swapper", pid 1, jiffies 4294897223
> > [   89.929480]   backtrace:
> > [   89.929480]     [<c0230695>] create_object+0x155/0x2c0
> > [   89.929480]     [<c0230dcb>] kmemleak_alloc+0x10b/0x1b0
> > [   89.929480]     [<c0228581>] kmem_cache_alloc+0x191/0x220
> > [   89.929480]     [<c03c9ecd>] reserve_range+0x52d/0x630
> > [   89.929480]     [<c03ca103>] reserve_resources_of_dev+0x133/0x150
> > [   89.929480]     [<c03ca12d>] system_pnp_probe+0xd/0x30
> > [   89.929480]     [<c03bb52d>] pnp_device_probe+0xed/0x1c0
> > [   89.929480]     [<c040d798>] really_probe+0x358/0x490
> > [   89.929480]     [<c040dada>] driver_probe_device+0xaa/0x150
> > [   89.929480]     [<c040dd69>] __driver_attach+0xb9/0x110
> > [   89.929480]     [<c040acf5>] bus_for_each_dev+0x65/0x90
> > [   89.929480]     [<c040ddde>] driver_attach+0x1e/0x30
> > [   89.929480]     [<c040baa2>] bus_add_driver+0x1a2/0x830
> > [   89.929480]     [<c040e568>] driver_register+0xc8/0x180
> > [   89.929480]     [<c03bb97c>] pnp_register_driver+0x1c/0x20
> > [   89.929480]     [<c1274c4d>] pnp_system_init+0xd/0x10

Here, the regionid allocated in reserve_range() is reported as a leak.

> > [   89.978981] unreferenced object 0xf65205a0 (size 32):
> > [   89.981599]   comm "swapper", pid 1, jiffies 4294897223
> > [   89.982969]   backtrace:
> > [   89.982969]     [<c0230695>] create_object+0x155/0x2c0
> > [   89.982969]     [<c0230dcb>] kmemleak_alloc+0x10b/0x1b0
> > [   89.982969]     [<c0228581>] kmem_cache_alloc+0x191/0x220
> > [   89.982969]     [<c016e29d>] __request_region+0x4cd/0x5d0
> > [   89.982969]     [<c03c9a6e>] reserve_range+0xce/0x630
> > [   89.982969]     [<c03ca103>] reserve_resources_of_dev+0x133/0x150
> > [   89.982969]     [<c03ca12d>] system_pnp_probe+0xd/0x30
> > [   89.982969]     [<c03bb52d>] pnp_device_probe+0xed/0x1c0
> > [   89.982969]     [<c040d798>] really_probe+0x358/0x490
> > [   89.982969]     [<c040dada>] driver_probe_device+0xaa/0x150
> > [   89.982969]     [<c040dd69>] __driver_attach+0xb9/0x110
> > [   89.982969]     [<c040acf5>] bus_for_each_dev+0x65/0x90
> > [   89.982969]     [<c040ddde>] driver_attach+0x1e/0x30
> > [   89.982969]     [<c040baa2>] bus_add_driver+0x1a2/0x830
> > [   89.982969]     [<c040e568>] driver_register+0xc8/0x180
> > [   89.982969]     [<c03bb97c>] pnp_register_driver+0x1c/0x20

The resource structure allocated in __request_region() cannot be found
to be referred either. It seems that the previous regionid leak may be
just a side effect of the above leak as the resource structure was
supposed to reference the regionid (via the name field).

For the above regionid and this one, you can dump the objects via
the /dev/kmem and get the name of the resource. You could also look
in /proc/iomem or /proc/ioports but if that's a real leak the resource
name shouldn't be there (but first check the reported leaks again via
the /sys/kernel/debug/kmemleak file).

Please keep me in the loop if you find any real leaks or they are just
false positives.

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/