linux-kernel - Re: kmemleak: Cannot insert 0xff7f1000 into the object search tree (overlaps existing)

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:	Fri, 12 Aug 2016 16:50:25 +0300
From:	Grygorii Strashko <grygorii.strashko@...com>
To:	Catalin Marinas <catalin.marinas@....com>
CC:	Vignesh R <vigneshr@...com>, <linux-mm@...ck.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>
Subject: Re: kmemleak: Cannot insert 0xff7f1000 into the object search tree
 (overlaps existing)

On 08/11/2016 08:08 PM, Catalin Marinas wrote:
> On Thu, Aug 11, 2016 at 07:48:12PM +0300, Grygorii Strashko wrote:
>> On 08/11/2016 06:54 PM, Catalin Marinas wrote:
>>> On Thu, Aug 11, 2016 at 05:20:51PM +0530, Vignesh R wrote:
>>>> I see the below message from kmemleak when booting linux-next on AM335x
>>>> GP EVM and DRA7 EVM
>>>
>>> Can you also reproduce it with 4.8-rc1?
>>>
>>>> [    0.803934] kmemleak: Cannot insert 0xff7f1000 into the object search tree (overlaps existing)
>>>> [    0.803950] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.8.0-rc1-next-20160809 #497
>>>> [    0.803958] Hardware name: Generic DRA72X (Flattened Device Tree)
>>>> [    0.803979] [<c0110104>] (unwind_backtrace) from [<c010c24c>] (show_stack+0x10/0x14)
>>>> [    0.803994] [<c010c24c>] (show_stack) from [<c0490df0>] (dump_stack+0xac/0xe0)
>>>> [    0.804010] [<c0490df0>] (dump_stack) from [<c0296f88>] (create_object+0x214/0x278)
>>>> [    0.804025] [<c0296f88>] (create_object) from [<c07c770c>] (kmemleak_alloc_percpu+0x54/0xc0)
>>>> [    0.804038] [<c07c770c>] (kmemleak_alloc_percpu) from [<c025fb08>] (pcpu_alloc+0x368/0x5fc)
>>>> [    0.804052] [<c025fb08>] (pcpu_alloc) from [<c0b1bfbc>] (crash_notes_memory_init+0x10/0x40)
>>>> [    0.804064] [<c0b1bfbc>] (crash_notes_memory_init) from [<c010188c>] (do_one_initcall+0x3c/0x178)
>>>> [    0.804075] [<c010188c>] (do_one_initcall) from [<c0b00e98>] (kernel_init_freeable+0x1fc/0x2c8)
>>>> [    0.804086] [<c0b00e98>] (kernel_init_freeable) from [<c07c66b0>] (kernel_init+0x8/0x114)
>>>> [    0.804098] [<c07c66b0>] (kernel_init) from [<c0107910>] (ret_from_fork+0x14/0x24)
>>>
>>> This is the allocation stack trace, going via pcpu_alloc().
>>>
>>>> [    0.804106] kmemleak: Kernel memory leak detector disabled
>>>> [    0.804113] kmemleak: Object 0xfe800000 (size 16777216):
>>>> [    0.804121] kmemleak:   comm "swapper/0", pid 0, jiffies 4294937296
>>>> [    0.804127] kmemleak:   min_count = -1
>>>> [    0.804132] kmemleak:   count = 0
>>>> [    0.804138] kmemleak:   flags = 0x5
>>>> [    0.804143] kmemleak:   checksum = 0
>>>> [    0.804149] kmemleak:   backtrace:
>>>> [    0.804155]      [<c0b26a90>] cma_declare_contiguous+0x16c/0x214
>>>> [    0.804170]      [<c0b3c9c0>] dma_contiguous_reserve_area+0x30/0x64
>>>> [    0.804183]      [<c0b3ca74>] dma_contiguous_reserve+0x80/0x94
>>>> [    0.804195]      [<c0b06810>] arm_memblock_init+0x130/0x184
>>>> [    0.804207]      [<c0b04214>] setup_arch+0x590/0xc08
>>>> [    0.804217]      [<c0b00940>] start_kernel+0x58/0x3b4
>>>> [    0.804227]      [<8000807c>] 0x8000807c
>>>> [    0.804237]      [<ffffffff>] 0xffffffff
>>>
>>> This seems to be the original object that was allocated via
>>> cma_declare_contiguous(): 16MB range from 0xfe800000 to 0xff800000.
>>> Since the pointer returned by pcpu_alloc is 0xff7f1000 falls in the 16MB
>>> CMA range, kmemleak gets confused (it doesn't allow overlapping
>>> objects).
>>>
>>> So what I think goes wrong is that the kmemleak_alloc(__va(found)) call
>>> in memblock_alloc_range_nid() doesn't get the right value for the VA of
>>> the CMA block. The memblock_alloc_range() call in
>>> cma_declare_contiguous() asks for memory above high_memory, hence on a
>>> 32-bit architecture with highmem enabled, __va() use is not really
>>> valid, returning the wrong address. The existing kmemleak object is
>>> bogus, it shouldn't have been created in the first place.
>>>
>>> Now I'm trying to figure out how to differentiate between lowmem
>>> memblocks and highmem ones. Ignoring the kmemleak_alloc() calls
>>> altogether in mm/memblock.c is probably not an option as it would lead
>>> to lots of false positives.
>>
>> But cma_declare_contiguous() calls -
>> 		/*
>> 		 * kmemleak scans/reads tracked objects for pointers to other
>> 		 * objects but this address isn't mapped and accessible
>> 		 */
>> 		kmemleak_ignore(phys_to_virt(addr));
>>
>> Does it means above code is incorrect also?
>
> Yes, as long as the phys_to_virt() use is invalid. You may get away with
> this, depending on the SoC. Also, kmemleak_ignore() here is meant to
> tell kmemleak not to bother with scanning or reporting such memory since
> it is not meant for pointers but it still keeps track of it. The only
> way to remove it from kmemleak is replace this with kmemleak_free(). But
> That's more of a hack since phys_to_virt(addr) is still invalid.
>
>> It's a little bit strange that this can be seen only now, because
>> commit 95b0e655f9 ("ARM: mm: don't limit default CMA region only to low memor")
>> is pretty old.
>
> You might want to double check my scenario above but I guess we've been
> lucky. So either some configuration changed and arm_dma_limit >
> arm_lowmem_limit or the random VA for the CMA memory didn't overlap with
> any other block.
>

Thanks a  lot for explanation.


-- 
regards,
-grygorii