linux-kernel - Re: [PATCH v2] bpf: Fix memory leak in copy

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]
Message-ID: <b29757e1-c7a2-dee9-bfa2-587407cadf50@iogearbox.net>
Date:   Tue, 16 Mar 2021 21:51:10 +0100
From:   Daniel Borkmann <daniel@...earbox.net>
To:     qiang.zhang@...driver.com, ast@...nel.org, andrii@...nel.org
Cc:     dvyukov@...gle.com, linux-kernel@...r.kernel.org,
        syzbot+44908bb56d2bfe56b28e@...kaller.appspotmail.com,
        bpf@...r.kernel.org
Subject: Re: [PATCH v2] bpf: Fix memory leak in copy_process()

On 3/15/21 9:58 AM, qiang.zhang@...driver.com wrote:
> From: Zqiang <qiang.zhang@...driver.com>

nit: I presume it should be s/Zqiang/Qiang Zhang/ as real name for 'From'
instead of abbreviation?

> The syzbot report a memleak follow:
> BUG: memory leak
> unreferenced object 0xffff888101b41d00 (size 120):
>    comm "kworker/u4:0", pid 8, jiffies 4294944270 (age 12.780s)
>    backtrace:
>      [<ffffffff8125dc56>] alloc_pid+0x66/0x560
>      [<ffffffff81226405>] copy_process+0x1465/0x25e0
>      [<ffffffff81227943>] kernel_clone+0xf3/0x670
>      [<ffffffff812281a1>] kernel_thread+0x61/0x80
>      [<ffffffff81253464>] call_usermodehelper_exec_work
>      [<ffffffff81253464>] call_usermodehelper_exec_work+0xc4/0x120
>      [<ffffffff812591c9>] process_one_work+0x2c9/0x600
>      [<ffffffff81259ab9>] worker_thread+0x59/0x5d0
>      [<ffffffff812611c8>] kthread+0x178/0x1b0
>      [<ffffffff8100227f>] ret_from_fork+0x1f/0x30
> 
> unreferenced object 0xffff888110ef5c00 (size 232):
>    comm "kworker/u4:0", pid 8414, jiffies 4294944270 (age 12.780s)
>    backtrace:
>      [<ffffffff8154a0cf>] kmem_cache_zalloc
>      [<ffffffff8154a0cf>] __alloc_file+0x1f/0xf0
>      [<ffffffff8154a809>] alloc_empty_file+0x69/0x120
>      [<ffffffff8154a8f3>] alloc_file+0x33/0x1b0
>      [<ffffffff8154ab22>] alloc_file_pseudo+0xb2/0x140
>      [<ffffffff81559218>] create_pipe_files+0x138/0x2e0
>      [<ffffffff8126c793>] umd_setup+0x33/0x220
>      [<ffffffff81253574>] call_usermodehelper_exec_async+0xb4/0x1b0
>      [<ffffffff8100227f>] ret_from_fork+0x1f/0x30
> 
> after the UMD process exits, the pipe_to_umh/pipe_from_umh and tgid
> need to be release.
> 
> Fixes: d71fa5c9763c ("bpf: Add kernel module with user mode driver that populates bpffs.")
> Reported-by: syzbot+44908bb56d2bfe56b28e@...kaller.appspotmail.com
> Signed-off-by: Zqiang <qiang.zhang@...driver.com>

nit: Ditto

> ---
>   v1->v2:
>   Judge whether the pointer variable tgid is valid.
> 
>   kernel/bpf/preload/bpf_preload_kern.c | 24 ++++++++++++++++++++----
>   1 file changed, 20 insertions(+), 4 deletions(-)
> 
> diff --git a/kernel/bpf/preload/bpf_preload_kern.c b/kernel/bpf/preload/bpf_preload_kern.c
> index 79c5772465f1..5009875f01d3 100644
> --- a/kernel/bpf/preload/bpf_preload_kern.c
> +++ b/kernel/bpf/preload/bpf_preload_kern.c
> @@ -4,6 +4,7 @@
>   #include <linux/module.h>
>   #include <linux/pid.h>
>   #include <linux/fs.h>
> +#include <linux/file.h>
>   #include <linux/sched/signal.h>
>   #include "bpf_preload.h"
>   
> @@ -20,6 +21,14 @@ static struct bpf_preload_ops umd_ops = {
>   	.owner = THIS_MODULE,
>   };
>   
> +static void bpf_preload_umh_cleanup(struct umd_info *info)
> +{
> +	fput(info->pipe_to_umh);
> +	fput(info->pipe_from_umh);
> +	put_pid(info->tgid);
> +	info->tgid = NULL;
> +}

The above is pretty much a reimplementation of ...

static void umd_cleanup(struct subprocess_info *info)
{
         struct umd_info *umd_info = info->data;

         /* cleanup if umh_setup() was successful but exec failed */
         if (info->retval) {
                 fput(umd_info->pipe_to_umh);
                 fput(umd_info->pipe_from_umh);
                 put_pid(umd_info->tgid);
                 umd_info->tgid = NULL;
         }
}

... so if there are ever changes to umd_cleanup() for additional resource
cleanup, we'd be missing those easily in bpf_preload_umh_cleanup(). I'd
suggest to refactor a common helper inside kernel/usermode_driver.c that
is then exported as symbol which the driver here can use.

>   static int preload(struct bpf_preload_info *obj)
>   {
>   	int magic = BPF_PRELOAD_START;
> @@ -61,8 +70,10 @@ static int finish(void)
>   	if (n != sizeof(magic))
>   		return -EPIPE;
>   	tgid = umd_ops.info.tgid;
> -	wait_event(tgid->wait_pidfd, thread_group_exited(tgid));
> -	umd_ops.info.tgid = NULL;
> +	if (tgid) {
> +		wait_event(tgid->wait_pidfd, thread_group_exited(tgid));
> +		bpf_preload_umh_cleanup(&umd_ops.info);
> +	}
>   	return 0;
>   }
>   
> @@ -80,10 +91,15 @@ static int __init load_umd(void)
>   
>   static void __exit fini_umd(void)
>   {
> +	struct pid *tgid;
>   	bpf_preload_ops = NULL;
>   	/* kill UMD in case it's still there due to earlier error */
> -	kill_pid(umd_ops.info.tgid, SIGKILL, 1);
> -	umd_ops.info.tgid = NULL;
> +	tgid = umd_ops.info.tgid;
> +	if (tgid) {
> +		kill_pid(tgid, SIGKILL, 1);
> +		wait_event(tgid->wait_pidfd, thread_group_exited(tgid));
> +		bpf_preload_umh_cleanup(&umd_ops.info);
> +	}
>   	umd_unload_blob(&umd_ops.info);
>   }
>   late_initcall(load_umd);
>