linux-kernel - Kmemleak and debug objects

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

Date:	Fri, 22 Jan 2016 13:54:25 +0300
From:	Evgenii Shatokhin <eugene.shatokhin@...dex.ru>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Kmemleak and debug objects

Hi,

When using Kmemleak on the kernel 3.10.0-229.7.2 x86_64 (RHEL 7 and the 
like) with CONFIG_DEBUG_OBJECTS=y, I sometimes see Kmemleak report the 
potential leaks of the following kind:

---------------
unreferenced object 0xffff8800270e32d0 (size 40):
   comm "updatedb", pid 14416, jiffies 4297905695 (age 4024.651s)
   hex dump (first 32 bytes):
     c0 2a 0e 27 00 88 ff ff f0 38 5c 84 ff ff ff ff  .*.'.....8\.....
     01 00 00 00 00 00 00 00 10 2f be 27 00 88 ff ff  ........./.'....
   backtrace:
     [<ffffffff82355fbe>] kmemleak_alloc+0x4e/0xc0
     [<ffffffff8156fc15>] kmem_cache_alloc+0x125/0x390
     [<ffffffff8192091d>] __debug_object_init+0x6bd/0xc40
     [<ffffffff81920ebb>] debug_object_init+0x1b/0x20
     [<ffffffff811adf89>] __init_work+0x19/0x30
     [<ffffffffa04a89a6>] ext4_alloc_inode+0x5c6/0x7f0 [ext4]
     [<ffffffff8161777b>] alloc_inode+0x5b/0x170
     [<ffffffff8161bb6b>] iget_locked+0xfb/0x2f0
     [<ffffffffa0448332>] ext4_iget+0x112/0x46f0 [ext4]
     [<ffffffffa044c998>] ext4_iget_normal+0x88/0xb0 [ext4]
     [<ffffffffa047149e>] ext4_lookup+0x29e/0x4e0 [ext4]
     [<ffffffff815df8d0>] lookup_real+0x90/0x120
     [<ffffffff815e1243>] __lookup_hash+0xe3/0x100
     [<ffffffff815e1d42>] lookup_slow+0xd2/0x280
     [<ffffffff815f1266>] path_lookupat+0x1ec6/0x4610
     [<ffffffff815f39fc>] filename_lookup+0x4c/0x1f0
---------------

If I trigger Kmemleak scan again, such objects are still reported in 
/sys/kernel/debug/kmemleak.

The object is an instance of 'struct debug_obj' and the first two 8-byte 
fields of it are the contents of 'struct hlist_node' (next, *pprev).

The object should be in a bucket of obj_hash (lib/debugobjects.c), 
namely the one at 0xffffffff845c38f0, as I can see from hlist_node::pprev.

I checked the memory - that element of obj_hash did actually contain the 
pointer to that object after Kmemleak had reported it as a potential leak.

Kmemleak scans the memory areas from .bss, including obj_hash, so it 
should probably have seen that pointer.

Looks like a false positive.

Is it a known problem?

Could it be that Kmemleak, say, saw that object after that had been 
allocated and removed from obj_pool but before it had been added to 
obj_hash? However, the subsequent scans would have shown in that case 
that the object is not leaked, I guess. Or, perhaps, something else 
causes this?

Any ideas?

Regards,
Evgenii