]> www.infradead.org Git - users/jedix/linux-maple.git/commit
bpf: Fix theoretical prog_array UAF in __uprobe_perf_func()
authorJann Horn <jannh@google.com>
Tue, 10 Dec 2024 19:08:14 +0000 (20:08 +0100)
committerAndrii Nakryiko <andrii@kernel.org>
Tue, 10 Dec 2024 21:06:51 +0000 (13:06 -0800)
commit7d0d673627e20cfa3b21a829a896ce03b58a4f1c
tree44e6d532745eaac00be5e56cdba837f1814bd5ac
parentc4441ca86afe4814039ee1b32c39d833c1a16bbc
bpf: Fix theoretical prog_array UAF in __uprobe_perf_func()

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.

Fix it by aligning the semantics to bpf_prog_run_array(): Let the caller
provide rcu_read_lock_trace() protection and then load call->prog_array
with rcu_dereference_check().

This issue seems to be theoretical: I don't know of any way to reach this
code without having handle_swbp() further up the stack, which is already
holding a rcu_read_lock_trace() lock, so where we take
rcu_read_lock_trace() in __uprobe_perf_func()/bpf_prog_run_array_uprobe()
doesn't actually have any effect.

Fixes: 8c7dcb84e3b7 ("bpf: implement sleepable uprobes by chaining gps")
Suggested-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20241210-bpf-fix-uprobe-uaf-v4-1-5fc8959b2b74@google.com
include/linux/bpf.h
kernel/trace/trace_uprobe.c