mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Qing Wang <wangqing7171@gmail.com>
To: Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	John Fastabend <john.fastabend@gmail.com>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Eduard Zingerman <eddyz87@gmail.com>, Song Liu <song@kernel.org>,
	Yonghong Song <yonghong.song@linux.dev>,
	KP Singh <kpsingh@kernel.org>,
	Stanislav Fomichev <sdf@fomichev.me>, Hao Luo <haoluo@google.com>,
	Jiri Olsa <jolsa@kernel.org>
Cc: bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
	Qing Wang <wangqing7171@gmail.com>,
	syzbot+b4c5ad098c821bf8d8bc@syzkaller.appspotmail.com
Subject: [PATCH v2] bpf: Fix use-after-free in __bpf_trace_run()
Date: Wed,  4 Mar 2026 17:23:45 +0800	[thread overview]
Message-ID: <20260304092345.233522-1-wangqing7171@gmail.com> (raw)

A use-after-free issue reported from syzbot exists in __bpf_trace_run().

BUG: KASAN: slab-use-after-free in __bpf_trace_run kernel/trace/bpf_trace.c:2075 [inline]
    -> struct bpf_prog *prog = link->link.prog;

The link(struct bpf_raw_tp_link) was freed before accessing
link->link.prog.

The root cause is that: When bpf_probe_unregister() is called, tasks may
have already entered the old tp_probes array (RCU read-side section)
before rcu_assign_pointer() updates tp->funcs. These tasks can access the
link through the old array. Without synchronization, the link can be freed
via call_rcu() after bpf_probe_unregister() in bpf_link_free(), leading to
use-after-free in __bpf_trace_run().

CPU 0 (free link)                    CPU 1 (enter old tp probe)
─────────────────                    ────────────────────────

                                     rcu_read_lock()
                                     old_funcs = tp->funcs
bpf_raw_tp_link_release()
bpf_probe_unregister()
rcu_assign_pointer(tp->funcs, new)
call_srcu/call_rcu_tasks_trace(old_tp)
...
call_rcu/call_rcu_tasks_trace(&link->rcu, ...)
(RCU grace period)
kfree(link)
                                     __bpf_trace_run(link, ...)
                                     access link->link.prog
                                     UAF!

Fix by calling tracepoint_synchronize_unregister() to ensure all
in-flight tracepoint callbacks have completed, so the link is no
longer reachable before it is freed.

The issue was introduced by commit d4dfc5700e86 ("bpf:
pass whole link instead of prog when triggering raw tracepoint"),
which changed tracepoint callbacks to receive bpf_raw_tp_link pointers
instead of bpf_prog pointers.

Prior to this commit, this issue did not occur because the bpf_prog was
directly used and protected by reference counting.

Fixes: d4dfc5700e86 ("bpf: pass whole link instead of prog when triggering raw tracepoint")
Reported-by: syzbot+b4c5ad098c821bf8d8bc@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=b4c5ad098c821bf8d8bc
Tested-by: syzbot+b4c5ad098c821bf8d8bc@syzkaller.appspotmail.com
Signed-off-by: Qing Wang <wangqing7171@gmail.com>
---
Changes in v2:
- Modified commit message from bpf-ci AI reviewed.
- Link to v1: https://lore.kernel.org/all/20260304070927.178464-1-wangqing7171@gmail.com/T/

 kernel/bpf/syscall.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 0378e83b4099..dd491bc35027 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -3783,6 +3783,13 @@ static void bpf_raw_tp_link_release(struct bpf_link *link)
 
 	bpf_probe_unregister(raw_tp->btp, raw_tp);
 	bpf_put_raw_tracepoint(raw_tp->btp);
+
+	/*
+	 * Wait for all in-flight tracepoint callbacks to complete so the
+	 * link is no longer reachable through tp_probes. This prevents
+	 * use-after-free in __bpf_trace_run() when a tracepoint fires.
+	 */
+	tracepoint_synchronize_unregister();
 }
 
 static void bpf_raw_tp_link_dealloc(struct bpf_link *link)
-- 
2.34.1


             reply	other threads:[~2026-03-04  9:24 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-04  9:23 Qing Wang [this message]
2026-03-05  1:38 ` Jordan Rife
2026-03-05  7:16   ` Qing Wang

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=20260304092345.233522-1-wangqing7171@gmail.com \
    --to=wangqing7171@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=sdf@fomichev.me \
    --cc=song@kernel.org \
    --cc=syzbot+b4c5ad098c821bf8d8bc@syzkaller.appspotmail.com \
    --cc=yonghong.song@linux.dev \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®