linux-kernel - Re: [PATCH] kernel/relay.c: fix memleak on destroy relay channel

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:   Mon, 17 Aug 2020 13:38:29 +0100
From:   Chris Wilson <chris@...is-wilson.co.uk>
To:     Akash Goel <akash.goel@...el.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Daniel Axtens <dja@...ens.net>,
        David Rientjes <rientjes@...gle.com>,
        Michael Ellerman <mpe@...erman.id.au>,
        Michel Lespinasse <walken@...gle.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Wei Yongjun <weiyongjun1@...wei.com>
Cc:     Wei Yongjun <weiyongjun1@...wei.com>, linux-kernel@...r.kernel.org,
        Hulk Robot <hulkci@...wei.com>
Subject: Re: [PATCH] kernel/relay.c: fix memleak on destroy relay channel

Quoting Wei Yongjun (2020-08-17 13:28:26)
> kmemleak report memory leak as follows:
> 
> unreferenced object 0x607ee4e5f948 (size 8):
> comm "syz-executor.1", pid 2098, jiffies 4295031601 (age 288.468s)
> hex dump (first 8 bytes):
> 00 00 00 00 00 00 00 00 ........
> backtrace:
> [<00000000ca1de2fa>] relay_open kernel/relay.c:583 [inline]
> [<00000000ca1de2fa>] relay_open+0xb6/0x970 kernel/relay.c:563
> [<0000000038ae5a4b>] do_blk_trace_setup+0x4a8/0xb20 kernel/trace/blktrace.c:557
> [<00000000d5e778e9>] __blk_trace_setup+0xb6/0x150 kernel/trace/blktrace.c:597
> [<0000000038fdf803>] blk_trace_ioctl+0x146/0x280 kernel/trace/blktrace.c:738
> [<00000000ce25a0ca>] blkdev_ioctl+0xb2/0x6a0 block/ioctl.c:613
> [<00000000579e47e0>] block_ioctl+0xe5/0x120 fs/block_dev.c:1871
> [<00000000b1588c11>] vfs_ioctl fs/ioctl.c:48 [inline]
> [<00000000b1588c11>] __do_sys_ioctl fs/ioctl.c:753 [inline]
> [<00000000b1588c11>] __se_sys_ioctl fs/ioctl.c:739 [inline]
> [<00000000b1588c11>] __x64_sys_ioctl+0x170/0x1ce fs/ioctl.c:739
> [<0000000088fc9942>] do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46
> [<000000004f6dd57a>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> 
> 'chan->buf' is malloced in relay_open() by alloc_percpu() but not free
> while destroy the relay channel. Fix it by adding free_percpu() before
> return from relay_destroy_channel().
> 
> Fixes: 017c59c042d0 ("relay: Use per CPU constructs for the relay channel buffer pointers")
> Reported-by: Hulk Robot <hulkci@...wei.com>
> Signed-off-by: Wei Yongjun <weiyongjun1@...wei.com>
> ---
>  kernel/relay.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/kernel/relay.c b/kernel/relay.c
> index 72fe443ea78f..fb4e0c530c08 100644
> --- a/kernel/relay.c
> +++ b/kernel/relay.c
> @@ -197,6 +197,7 @@ static struct rchan_buf *relay_create_buf(struct rchan *chan)
>  static void relay_destroy_channel(struct kref *kref)
>  {
>         struct rchan *chan = container_of(kref, struct rchan, kref);
> +       free_percpu(chan->buf);
>         kfree(chan);

That catches the error path for relay_open as well, and the fixes is
correct. Worth a cc:stable, #v4.9+?

Reviewed-by: Chris Wilson <chris@...is-wilson.co.uk>
-Chris