linux-kernel - Re: [PATCH] mm: kmemleak: start address align for scan_large

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:   Wed, 11 Oct 2017 10:42:49 +0100
From:   Catalin Marinas <catalin.marinas@....com>
To:     shuwang@...hat.com
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org, chuhu@...hat.com,
        yizhan@...hat.com
Subject: Re: [PATCH] mm: kmemleak: start address align for scan_large_block

On Wed, Oct 11, 2017 at 04:53:34PM +0800, shuwang@...hat.com wrote:
> From: Shu Wang <shuwang@...hat.com>
> 
> If the start address is not ptr bytes aligned, it may cause false
> positives when a pointer is split by MAX_SCAN_SIZE.
> 
> For example:
> tcp_metrics_nl_family is in __ro_after_init area. On my PC, the
> __start_ro_after_init is not ptr aligned, and
> tcp_metrics_nl_family->attrbuf was break by MAX_SCAN_SIZE.
> 
>  # cat /proc/kallsyms | grep __start_ro_after_init
>  ffffffff81afac8b R __start_ro_after_init
> 
>  (gdb) p &tcp_metrics_nl_family->attrbuf
>    (struct nlattr ***) 0xffffffff81b12c88 <tcp_metrics_nl_family+72>
> 
>  (gdb) p tcp_metrics_nl_family->attrbuf
>    (struct nlattr **) 0xffff88007b9d9400
> 
>  scan_block(_start=0xffffffff81b11c8b, _end=0xffffffff81b12c8b, 0)
>  scan_block(_start=0xffffffff81b12c8b, _end=0xffffffff81b13c8b, 0)
> 
> unreferenced object 0xffff88007b9d9400 (size 128):
>   backtrace:
>     kmemleak_alloc+0x4a/0xa0
>     __kmalloc+0xec/0x220
>     genl_register_family.part.8+0x11c/0x5c0
>     genl_register_family+0x6f/0x90
>     tcp_metrics_init+0x33/0x47
>     tcp_init+0x27a/0x293
>     inet_init+0x176/0x28a
>     do_one_initcall+0x51/0x1b0
> 
> Signed-off-by: Shu Wang <shuwang@...hat.com>

Nice catch. Thanks.

Reviewed-by: Catalin Marinas <catalin.marinas@....com>