On Thu, Aug 13, 2026 at 4:35 PM Peter Zijlstra <[email protected]> wrote: >
> As I said yesterday, how can perf_event_detach_bpf_prog() run > concurrently with __perf_event_overflow()? Unless you answer that, this > patch ain't moving nowhere. > You are right to question this. The KCSAN report from syzbot shows the race was detected at runtime: I don't have evidence to prove this race condition. > > 3. perf_event_alloc() reads parent_event->prog locklessly during > > fork() which can race with a concurrent detach clearing and freeing > > the prog, potentially causing a NULL pointer dereference or > > use-after-free in bpf_prog_inc(). Fix by holding bpf_event_mutex > > when inheriting the BPF program. Make bpf_event_mutex non-static > > and declare it extern in perf_event.h so it is accessible from > > kernel/events/core.c. > > This seems like a separate issue and should thus be a separate patch. Agreed. I will split the perf_event_alloc() fix into a separate patch. Thanks Deepanshu
