All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: zafir.taufik@starlabs.sg
Cc: linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH] tracing: uprobes: Fix slab use-after-free in filter_chain
Date: Thu, 10 Sep 2026 02:48:49 +0000	[thread overview]
Message-ID: <20260910024850.6E3351F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260910023106.1795811-3-zafir.taufik@starlabs.sg>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Race condition in unregister_trace_uprobe leads to use-after-free (UAF) of trace_uprobe during lockless read accesses.
--

commit 04fcafa318e6d04f74e677950139db1dd3bf079c
Author: Zafir Rasyidi Taufik <zafir.taufik@starlabs.sg>

tracing: uprobes: Fix slab use-after-free in filter_chain

This commit addresses a use-after-free in uprobe_mmap. It resolves an issue
where unregister_trace_uprobe() would fail to unlink the consumer when a
trace_probe has a sibling event.

> diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
> index 861d857adadb3..110ec7b78b3dc 100644
> --- a/kernel/trace/trace_uprobe.c
> +++ b/kernel/trace/trace_uprobe.c
> @@ -408,6 +408,11 @@ static int unregister_trace_uprobe(struct trace_uprobe *tu)
>  		return ret;
>  
>  unreg:
> +	if (tu->uprobe) {
> +		uprobe_unregister_nosync(tu->uprobe, &tu->consumer);
> +		tu->uprobe = NULL;
> +		uprobe_unregister_sync();
> +	}
>  	dyn_event_remove(&tu->devent);
>  	trace_probe_unlink(&tu->tp);
>  	free_trace_uprobe(tu);

[Severity: Critical]
This is a pre-existing issue, but does this code leave a window for a
use-after-free of trace_uprobe during lockless read accesses?

When a sibling probe exists, this code unlinks and immediately frees the
trace probe without synchronizing with trace readers via RCU or shared locks.

For example, when a user queries an attached perf event, it initiates a
lockless traversal:

bpf_task_fd_query()
  bpf_get_perf_event_info()
    bpf_get_uprobe_info()
      trace_uprobe_primary_from_call()

This accesses the trace probe structure without acquiring event_mutex or
trace_event_sem.

Additionally, even if trace_event_sem is held for read, such as during
print_uprobe_event(), unregister_trace_uprobe() bypasses taking
trace_event_sem for write when unregistering a sibling probe (it skips
unregister_uprobe_event() and jumps directly to unreg).

At the same time, if unregister_trace_uprobe() is called, it unlinks the
probe via trace_probe_unlink(). The list removal relies on standard
list_del_init() instead of list_del_rcu(), allowing concurrent lockless
readers to traverse into soon-to-be-freed nodes when free_trace_uprobe(tu)
is called immediately after.

Could this lead to memory corruption when readers access the freed probe?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260910023106.1795811-3-zafir.taufik@starlabs.sg?part=1

  reply	other threads:[~2026-09-10  2:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-10  2:31 [PATCH] tracing: uprobes: Fix slab use-after-free in filter_chain zafir.taufik
2026-09-10  2:48 ` sashiko-bot [this message]
2026-09-10  5:24   ` Zafir Rasyidi Taufik

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=20260910024850.6E3351F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=zafir.taufik@starlabs.sg \
    /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.