> commit ba658ac0ee57b66edf6626745df8d57173c68285
> Author: Deepanshu Kartikey <[email protected]>
> Date: Fri Aug 21 07:12:10 2026 +0530
>
> perf/bpf: Fix lockless access to parent_event->prog in perf_event_alloc()
>
> During fork(), perf_event_alloc() reads parent_event->prog locklessly
> which can race with a concurrent bpf_perf_link_release() clearing and
> freeing the prog via perf_event_detach_bpf_prog(). This can result in
> a NULL pointer dereference or use-after-free in bpf_prog_inc().
>
> Fix by holding bpf_event_mutex when inheriting the BPF program during
> fork(). Make bpf_event_mutex non-static and declare it extern in
> perf_event.h so it is accessible from kernel/events/core.c.
>
> Fixes: 85192dbf4de0 ("bpf: Convert bpf_prog refcnt to atomic64_t")
The Fixes tag points at commit 85192dbf4de0 ("bpf: Convert bpf_prog
refcnt to atomic64_t") by Andrii Nakryiko, which only converted
bpf_prog->aux->refcnt from atomic_t to atomic64_t and made bpf_prog_inc()
non-failing.
That commit's modified-symbol set is entirely in kernel/bpf/,
include/linux/bpf.h and various net drivers, and it does not touch
kernel/events/core.c or perf_event_alloc() at all.
The unlocked read of parent_event->prog in perf_event_alloc() predates
it and was introduced by the commit that added BPF overflow-handler
inheritance to perf_event_alloc().
Should the Fixes tag name the commit that introduced the unlocked read so
the fix is backported to the right stable trees?
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/32437947108
