From nobody Mon Apr 13 21:01:12 2026 Received: from mail-wm1-f66.google.com (mail-wm1-f66.google.com [209.85.128.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 564053932F1 for ; Wed, 4 Mar 2026 09:24:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.66 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772616242; cv=none; b=RJXUitHatPCYjkAhAQBDiBrWvzhz/NhrQGRiDmX9L2okICdBc37DFBno/GWd40gN6edOwhZ1Pb9xxOlAw/WmRCzCKu5ROVf+phAQDAMpZPUhtPMvMPC4eL6d1nVwGSWIMItqZCU36C//QegKlO/5ZCMuvxCd+nXMtc0Xh2nev9U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772616242; c=relaxed/simple; bh=U0eVh8rknoxQ5P/LRl2C58ozsqVbhU5VVy2wI8/KjNk=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version:Content-Type; b=BpTJcjJUVqR4WiYmUyjJxbnUq5LIBPfxLd+ZOF5msY/Zqa/7nyi/GDY9rMdletQICPz4PNhJVLrj9ALZpAwJmWlV2LTS/CmdezMbGZANPu1vU7nuAKVQ39Xr5mlP6pyoCfo1uKfxwMg0KHL3YSNfKNq2B7+bbmkA+kgMiZjgiWc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=iEa+tR+O; arc=none smtp.client-ip=209.85.128.66 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="iEa+tR+O" Received: by mail-wm1-f66.google.com with SMTP id 5b1f17b1804b1-483703e4b08so62468105e9.1 for ; Wed, 04 Mar 2026 01:24:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772616240; x=1773221040; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=TkBHgTSYQa7hABaWg7+/qV6sPwNl26cwPEJnQ76iATQ=; b=iEa+tR+OAZspNCY8g/fwcu5KWztPG3GT5F9Ch28rBxjALnM7UGTru78mVEqyUzOzEZ 60Wosp2/YQyZH/Sr51ku1RQJM1XZU75ltpbGZCQ46wju07ylLTFabqnM65NSV2c6d31p lGlffNCr+Zn4tYhJvEwgvGkfPcNGMMOI4CQJhZoi0fJNBgSpsAYvB6gNJJlgV8PyCPFz yNcN6qnUN6YNrxLoSuE2roZRxB1YjG3gZHmHx6eDf44gnaKi/wOkb+Tiw35B3WXK7uIO A6pEN73njn9m/QgezRF7FsZlpmZSdUS9A2y/GZm5MA5e96ogTOcmrgq2+bM0O7tu8m4a yPLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772616240; x=1773221040; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=TkBHgTSYQa7hABaWg7+/qV6sPwNl26cwPEJnQ76iATQ=; b=NNbGvhn4qdTy4Fmv6kCEhI6mYybxmIfeHSkFVr5U4t3dxkZvdyNBpQ/6tmwWdZiX25 Y3AulG7kvUGisLfaBHxLF7/uEXXJjwIMOBMp+wm9CM2XCeTp6EQtTkAi7DBM69KAVezI KPnWk/2j5LzJNWE4iJw3UdpaH0axEQ/+5pK+CyduMdZjUPRQ5E8qVf5LeGeLZIjQmzrj GkRc0qJYWKENz019UVbtuGRgYPxepemdQMh3RlFOKEjR48T//+P8EEw06ASAEFp9jaj2 zuyGMzUcpRB4ultUu3ciQo1F9/oWCrL1oq9ipr3m0F1lrY8Szp4j/2HKTSSXj3BFnjnE GbyA== X-Forwarded-Encrypted: i=1; AJvYcCVHvkGknGVq9gY6ICwIQZeWEM7lUX0vNYoVbBlcOk7lc7FJUDWeTje9SBiwzqBpGrLwHAh8NGflTazGcoY=@vger.kernel.org X-Gm-Message-State: AOJu0Ywrn8IltoB7t/YZBfjlaPUP0FW/XyMw2ycpTezo8Dsg9+6QnCNO tGzt2Gwm4WexB4J7j3Xxh/YEI8rfy2R+mj7qc05hgwaDxAjqGL6tuBRT X-Gm-Gg: ATEYQzzssxNY3uCBaBp8SUOjCEumjKyIJhefXOq73TjubTb1fMDhG4W+rDcQ03IkyB8 CCGh3UBZUSsy6qgo96i2RVQFEiql8MUmS8E/bplHLMuqUG2PlYI3MdIqcIUIEgy8lBn0xsyQQiQ gA5kbK1KGtFj4a9nvUZd8efdXiH1a59D8g2ypyTzcfDvJ7fn3EEnpJ60n+QiGLdawEdoqSGXp0H zN3dVYLC+uqkFwXDd/+e+fYK9A+v+nd4iBxghiotxhCaeZlvn/+nWOfjDYPvImNDLCK5D8YewfY /N465ED7o9j8uh3d0WhUgtGrCqFoqwCxNOG8YBDwwZPQy8Y/D5oy8eo2AVX4wjtF5rOAOy1XfQ+ zPxbZkxdpwZ/md07BMJIzBNYdNM2NANR4Q40gBizA07KNISRq939iV6OkU03pnjnB8QfrE9xo7g 2G52Kx9Qa6R/7o0e9se8uJLcD4Jh3Znhm7SfVz5rN1kqiAgxl1aA== X-Received: by 2002:a05:600c:4695:b0:46e:59bd:f7e2 with SMTP id 5b1f17b1804b1-485198becb2mr21116885e9.11.1772616239290; Wed, 04 Mar 2026 01:23:59 -0800 (PST) Received: from lima-ubuntu.hz.ali.com ([47.246.98.208]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4851884225asm38570725e9.6.2026.03.04.01.23.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Mar 2026 01:23:58 -0800 (PST) From: Qing Wang To: Alexei Starovoitov , Daniel Borkmann , John Fastabend , Andrii Nakryiko , Martin KaFai Lau , Eduard Zingerman , Song Liu , Yonghong Song , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa Cc: bpf@vger.kernel.org, linux-kernel@vger.kernel.org, Qing Wang , 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 Message-Id: <20260304092345.233522-1-wangqing7171@gmail.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 =3D 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) =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80 =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80 rcu_read_lock() old_funcs =3D 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=3Db4c5ad098c821bf8d8bc Tested-by: syzbot+b4c5ad098c821bf8d8bc@syzkaller.appspotmail.com Signed-off-by: Qing Wang --- Changes in v2: - Modified commit message from bpf-ci AI reviewed. - Link to v1: https://lore.kernel.org/all/20260304070927.178464-1-wangqing7= 171@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) =20 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(); } =20 static void bpf_raw_tp_link_dealloc(struct bpf_link *link) --=20 2.34.1