linux-kernel - Re: [PATCH] ftrace: Fix use-after-free issue in ftrace

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: <20240410112823.1d084c8f@gandalf.local.home>
Date: Wed, 10 Apr 2024 11:28:23 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Zheng Yejian <zhengyejian1@...wei.com>
Cc: <mhiramat@...nel.org>, <mark.rutland@....com>,
 <mathieu.desnoyers@...icios.com>, <linux-kernel@...r.kernel.org>,
 <linux-trace-kernel@...r.kernel.org>
Subject: Re: [PATCH] ftrace: Fix use-after-free issue in ftrace_location()

On Mon, 1 Apr 2024 20:55:43 +0800
Zheng Yejian <zhengyejian1@...wei.com> wrote:

> KASAN reports a bug:
> 
>   BUG: KASAN: use-after-free in ftrace_location+0x90/0x120
>   Read of size 8 at addr ffff888141d40010 by task insmod/424
>   CPU: 8 PID: 424 Comm: insmod Tainted: G        W          6.9.0-rc2+ #213
>   [...]
>   Call Trace:
>    <TASK>
>    dump_stack_lvl+0x68/0xa0
>    print_report+0xcf/0x610
>    kasan_report+0xb5/0xe0
>    ftrace_location+0x90/0x120
>    register_kprobe+0x14b/0xa40
>    kprobe_init+0x2d/0xff0 [kprobe_example]
>    do_one_initcall+0x8f/0x2d0
>    do_init_module+0x13a/0x3c0
>    load_module+0x3082/0x33d0
>    init_module_from_file+0xd2/0x130
>    __x64_sys_finit_module+0x306/0x440
>    do_syscall_64+0x68/0x140
>    entry_SYSCALL_64_after_hwframe+0x71/0x79
> 
> The root cause is that when lookup_rec() is lookuping ftrace record of
> an address in some module, and at the same time in ftrace_release_mod(),
> the memory that saving ftrace records has been freed as that module is
> being deleted.
> 
>   register_kprobes() {
>     check_kprobe_address_safe() {
>       arch_check_ftrace_location() {
>         ftrace_location() {
>           lookup_rec()  // access memory that has been freed by
>                         // ftrace_release_mod() !!!
> 
> It seems that the ftrace_lock is required when lookuping records in
> ftrace_location(), so is ftrace_location_range().
> 
> Fixes: ae6aa16fdc16 ("kprobes: introduce ftrace based optimization")
> Signed-off-by: Zheng Yejian <zhengyejian1@...wei.com>
> ---
>  kernel/trace/ftrace.c | 28 ++++++++++++++++++----------
>  1 file changed, 18 insertions(+), 10 deletions(-)
> 
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index da1710499698..838d175709c1 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -1581,7 +1581,7 @@ static struct dyn_ftrace *lookup_rec(unsigned long start, unsigned long end)
>  }
>  
>  /**
> - * ftrace_location_range - return the first address of a traced location
> + * ftrace_location_range_locked - return the first address of a traced location
>   *	if it touches the given ip range
>   * @start: start of range to search.
>   * @end: end of range to search (inclusive). @end points to the last byte
> @@ -1592,7 +1592,7 @@ static struct dyn_ftrace *lookup_rec(unsigned long start, unsigned long end)
>   * that is either a NOP or call to the function tracer. It checks the ftrace
>   * internal tables to determine if the address belongs or not.
>   */
> -unsigned long ftrace_location_range(unsigned long start, unsigned long end)
> +static unsigned long ftrace_location_range_locked(unsigned long start, unsigned long end)
>  {
>  	struct dyn_ftrace *rec;
>  
> @@ -1603,6 +1603,17 @@ unsigned long ftrace_location_range(unsigned long start, unsigned long end)
>  	return 0;
>  }
>  
> +unsigned long ftrace_location_range(unsigned long start, unsigned long end)
> +{
> +	unsigned long loc;
> +
> +	mutex_lock(&ftrace_lock);
> +	loc = ftrace_location_range_locked(start, end);
> +	mutex_unlock(&ftrace_lock);

I'm not so sure we can take a mutex in all places that call this function.

What about using RCU?

	rcu_read_lock();
	loc = ftrace_location_range_rcu(start, end);
	rcu_read_unlock();

Then in ftrace_release_mod() we can have:

 out_unlock:
	mutex_unlock();

	/* Need to synchronize with ftrace_location() */
	if (tmp_pages)
		synchronize_rcu();

-- Steve


> +
> +	return loc;
> +}
> +
>  /**
>   * ftrace_location - return the ftrace location
>   * @ip: the instruction pointer to check
> @@ -1614,25 +1625,22 @@ unsigned long ftrace_location_range(unsigned long start, unsigned long end)
>   */
>  unsigned long ftrace_location(unsigned long ip)
>  {
> -	struct dyn_ftrace *rec;
> +	unsigned long loc;
>  	unsigned long offset;
>  	unsigned long size;
>  
> -	rec = lookup_rec(ip, ip);
> -	if (!rec) {
> +	loc = ftrace_location_range(ip, ip);
> +	if (!loc) {
>  		if (!kallsyms_lookup_size_offset(ip, &size, &offset))
>  			goto out;
>  
>  		/* map sym+0 to __fentry__ */
>  		if (!offset)
> -			rec = lookup_rec(ip, ip + size - 1);
> +			loc = ftrace_location_range(ip, ip + size - 1);
>  	}
>  
> -	if (rec)
> -		return rec->ip;
> -
>  out:
> -	return 0;
> +	return loc;
>  }
>  
>  /**