[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id:
<173386622902.984066.17756652143302232987.git-patchwork-notify@kernel.org>
Date: Tue, 10 Dec 2024 21:30:29 +0000
From: patchwork-bot+netdevbpf@...nel.org
To: Jann Horn <jannh@...gle.com>
Cc: ast@...nel.org, daniel@...earbox.net, john.fastabend@...il.com,
andrii@...nel.org, martin.lau@...ux.dev, eddyz87@...il.com, song@...nel.org,
yonghong.song@...ux.dev, kpsingh@...nel.org, sdf@...ichev.me,
haoluo@...gle.com, jolsa@...nel.org, rostedt@...dmis.org,
mhiramat@...nel.org, mathieu.desnoyers@...icios.com, delyank@...com,
bpf@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-trace-kernel@...r.kernel.org
Subject: Re: [PATCH bpf v4] bpf: Fix theoretical prog_array UAF in
__uprobe_perf_func()
Hello:
This patch was applied to bpf/bpf.git (master)
by Andrii Nakryiko <andrii@...nel.org>:
On Tue, 10 Dec 2024 20:08:14 +0100 you wrote:
> Currently, the pointer stored in call->prog_array is loaded in
> __uprobe_perf_func(), with no RCU annotation and no immediately visible
> RCU protection, so it looks as if the loaded pointer can immediately be
> dangling.
> Later, bpf_prog_run_array_uprobe() starts a RCU-trace read-side critical
> section, but this is too late. It then uses rcu_dereference_check(), but
> this use of rcu_dereference_check() does not actually dereference anything.
>
> [...]
Here is the summary with links:
- [bpf,v4] bpf: Fix theoretical prog_array UAF in __uprobe_perf_func()
https://git.kernel.org/bpf/bpf/c/7d0d673627e2
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
Powered by blists - more mailing lists