All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <olsajiri@gmail.com>
To: Daniel Borkmann <daniel@iogearbox.net>
Cc: Oleg Nesterov <oleg@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrii Nakryiko <andrii@kernel.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Max Makarov <maxpain@linux.com>,
	bpf@vger.kernel.org, Steven Rostedt <rostedt@goodmis.org>,
	linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH] uprobes: Fix race in uprobe_free_utask
Date: Thu, 9 Jan 2025 21:49:43 +0100	[thread overview]
Message-ID: <Z4A2Z6wzwXLePriB@krava> (raw)
In-Reply-To: <af5b64ae-3917-4083-930b-b8e41d3a98d7@iogearbox.net>

On Thu, Jan 09, 2025 at 03:41:26PM +0100, Daniel Borkmann wrote:
> On 1/9/25 3:14 PM, Jiri Olsa wrote:
> > Max Makarov reported kernel panic [1] in perf user callchain code.
> > 
> > The reason for that is the race between uprobe_free_utask and bpf
> > profiler code doing the perf user stack unwind and is triggered
> > within uprobe_free_utask function:
> >    - after current->utask is freed and
> >    - before current->utask is set to NULL
> > 
> >   general protection fault, probably for non-canonical address 0x9e759c37ee555c76: 0000 [#1] SMP PTI
> >   RIP: 0010:is_uprobe_at_func_entry+0x28/0x80
> >   ...
> >    ? die_addr+0x36/0x90
> >    ? exc_general_protection+0x217/0x420
> >    ? asm_exc_general_protection+0x26/0x30
> >    ? is_uprobe_at_func_entry+0x28/0x80
> >    perf_callchain_user+0x20a/0x360
> >    get_perf_callchain+0x147/0x1d0
> >    bpf_get_stackid+0x60/0x90
> >    bpf_prog_9aac297fb833e2f5_do_perf_event+0x434/0x53b
> >    ? __smp_call_single_queue+0xad/0x120
> >    bpf_overflow_handler+0x75/0x110
> >    ...
> >    asm_sysvec_apic_timer_interrupt+0x1a/0x20
> >   RIP: 0010:__kmem_cache_free+0x1cb/0x350
> >   ...
> >    ? uprobe_free_utask+0x62/0x80
> >    ? acct_collect+0x4c/0x220
> >    uprobe_free_utask+0x62/0x80
> >    mm_release+0x12/0xb0
> >    do_exit+0x26b/0xaa0
> >    __x64_sys_exit+0x1b/0x20
> >    do_syscall_64+0x5a/0x80
> > 
> > It can be easily reproduced by running following commands in
> > separate terminals:
> > 
> >    # while :; do bpftrace -e 'uprobe:/bin/ls:_start  { printf("hit\n"); }' -c ls; done
> >    # bpftrace -e 'profile:hz:100000 { @[ustack()] = count(); }'
> > 
> > Fixing this by making sure current->utask pointer is set to NULL
> > before we start to release the utask object.
> 
> Lets add Fixes tag for stable team:
> 
> Fixes: cfa7f3d2c526 ("perf,x86: avoid missing caller address in stack traces captured in uprobe")

ugh right, thanks for finding that

jirka

> 
> > [1] https://github.com/grafana/pyroscope/issues/3673
> > Reported-by: Max Makarov <maxpain@linux.com>
> > Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> 
> fwiw, the other version we were potentially thinking of was below, but
> just moving the t->utask NULL assignment seemed better.
> 
> Thanks,
> Daniel
> 
> diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
> index c75c482d4c52..05f9cedf2691 100644
> --- a/arch/x86/events/core.c
> +++ b/arch/x86/events/core.c
> @@ -2835,6 +2835,8 @@ static bool is_uprobe_at_func_entry(struct pt_regs *regs)
> 
>         if (!current->utask)
>                 return false;
> +       if (!current->utask->active_uprobe)
> +               return false;
> 
>         auprobe = current->utask->auprobe;
>         if (!auprobe)

  reply	other threads:[~2025-01-09 20:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-09 14:14 [PATCH] uprobes: Fix race in uprobe_free_utask Jiri Olsa
2025-01-09 14:24 ` Oleg Nesterov
2025-01-09 14:41 ` Daniel Borkmann
2025-01-09 20:49   ` Jiri Olsa [this message]
2025-01-09 22:13 ` Andrii Nakryiko
2025-01-10  8:40 ` [tip: perf/urgent] " tip-bot2 for Jiri Olsa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z4A2Z6wzwXLePriB@krava \
    --to=olsajiri@gmail.com \
    --cc=andrii@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=maxpain@linux.com \
    --cc=mhiramat@kernel.org \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.