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: <YuKAlk+p/ABzfUQ+@krava>
Date:   Thu, 28 Jul 2022 14:27:02 +0200
From:   Jiri Olsa <olsajiri@...il.com>
To:     Xu Kuohai <xukuohai@...weicloud.com>
Cc:     bpf@...r.kernel.org, netdev@...r.kernel.org,
        Bruno Goncalves <bgoncalv@...hat.com>,
        Song Liu <song@...nel.org>
Subject: Re: [PATCH bpf-next] bpf: Fix NULL pointer dereference when
 registering bpf trampoline

On Thu, Jul 28, 2022 at 07:40:48AM -0400, Xu Kuohai wrote:
> From: Xu Kuohai <xukuohai@...wei.com>

SNIP

> 
> It's caused by a NULL tr->fops passed to ftrace_set_filter_ip(). tr->fops
> is initialized to NULL and is assigned to an allocated memory address if
> CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS is enabled. Since there is no
> direct call on arm64 yet, the config can't be enabled.
> 
> To fix it, call ftrace_set_filter_ip() only if tr->fops is not NULL.
> 
> Fixes: 00963a2e75a8 ("bpf: Support bpf_trampoline on functions with IPMODIFY (e.g. livepatch)")
> Reported-by: Bruno Goncalves <bgoncalv@...hat.com>
> Signed-off-by: Xu Kuohai <xukuohai@...wei.com>
> Tested-by: Bruno Goncalves <bgoncalv@...hat.com>
> Acked-by: Song Liu <songliubraving@...com>
> ---
>  kernel/bpf/trampoline.c | 11 +++++++++--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/bpf/trampoline.c b/kernel/bpf/trampoline.c
> index 42e387a12694..0d5a9e0b9a7b 100644
> --- a/kernel/bpf/trampoline.c
> +++ b/kernel/bpf/trampoline.c
> @@ -255,8 +255,15 @@ static int register_fentry(struct bpf_trampoline *tr, void *new_addr)
>  		return -ENOENT;
>  
>  	if (tr->func.ftrace_managed) {
> -		ftrace_set_filter_ip(tr->fops, (unsigned long)ip, 0, 0);
> -		ret = register_ftrace_direct_multi(tr->fops, (long)new_addr);
> +		if (tr->fops)
> +			ret = ftrace_set_filter_ip(tr->fops, (unsigned long)ip,
> +						   0, 0);
> +		else
> +			ret = -ENOTSUPP;
> +
> +		if (!ret)
> +			ret = register_ftrace_direct_multi(tr->fops,
> +							   (long)new_addr);
>  	} else {
>  		ret = bpf_arch_text_poke(ip, BPF_MOD_CALL, NULL, new_addr);
>  	}

do we need to do the same also in unregister_fentry and modify_fentry ?

jirka

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ