linux-kernel - Re: [PATCH] fork: fix kmemleak false positive due to thread stacks caching

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: <20170526142254.GB30853@e104818-lin.cambridge.arm.com>
Date:   Fri, 26 May 2017 15:22:54 +0100
From:   Catalin Marinas <catalin.marinas@....com>
To:     Luis Henriques <lhenriques@...e.com>
Cc:     Andy Lutomirski <luto@...nel.org>, Ingo Molnar <mingo@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Michal Hocko <mhocko@...e.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "Eric W . Biederman" <ebiederm@...ssion.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Oleg Nesterov <oleg@...hat.com>,
        Mateusz Guzik <mguzik@...hat.com>,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH] fork: fix kmemleak false positive due to thread stacks
 caching

On Fri, May 26, 2017 at 02:49:49PM +0100, Luis Henriques wrote:
> kmemleak has been reporting memory leaks since commit ac496bf48d97 ("fork:
> Optimize task creation by caching two thread stacks per CPU if
> CONFIG_VMAP_STACK=y"):
> 
> unreferenced object 0xffffc900002b0000 (size 16384):
>   comm "init", pid 147, jiffies 4294893306 (age 11.292s)
>   hex dump (first 32 bytes):
>     9d 6e ac 57 00 00 00 00 00 00 00 00 00 00 00 00  .n.W............
>     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>   backtrace:
>     [<ffffffff815b481e>] kmemleak_alloc+0x4e/0xb0
>     [<ffffffff8112a8b0>] __vmalloc_node_range+0x160/0x240
>     [<ffffffff8104a328>] copy_process.part.8+0x478/0x1630
>     [<ffffffff8104b69a>] _do_fork+0xca/0x330
>     [<ffffffff8104b9a9>] SyS_clone+0x19/0x20
>     [<ffffffff8100199c>] do_syscall_64+0x4c/0xb0
>     [<ffffffff815b8d06>] return_from_SYSCALL_64+0x0/0x6a
>     [<ffffffffffffffff>] 0xffffffffffffffff
> 
> This is because this commit started caching 2 thread stacks per CPU, and
> kmemleak assumes its memory is never freed.  Report these stacks as not
> being memory leaks using kmemleak_not_leak().
> 
> Cc: stable@...r.kernel.org
> Fixes: ac496bf48d97 ("fork: Optimize task creation by caching two thread stacks per CPU if CONFIG_VMAP_STACK=y")
> Signed-off-by: Luis Henriques <lhenriques@...e.com>

I guess that's meant as a 4.12 and earlier fix until the
kmemleak_vmalloc() patches go in
(http://lkml.kernel.org/r/1495726937-23557-1-git-send-email-catalin.marinas@arm.com)

> diff --git a/kernel/fork.c b/kernel/fork.c
> index aa1076c5e4a9..c4d79ad0f5bc 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -255,6 +255,7 @@ static inline void free_thread_stack(struct task_struct *tsk)
>  
>  			this_cpu_write(cached_stacks[i], tsk->stack_vm_area);
>  			local_irq_restore(flags);
> +			kmemleak_not_leak(tsk->stack);

I would add a comment here on why the annotation is needed.

The disadvantage is that such objects would no longer be detected as
leaks since kmemleak doesn't have a way to "unignore" an object (I have
a patch but not worth merging since we'll fix the above with a dedicated
kmemleak_vmalloc() API). We could however work around this with the
current kmemleak API as in this patch:

http://lkml.kernel.org/r/20170516133925.GA9453@e104818-lin.cambridge.arm.com

Thanks.

-- 
Catalin