Re: [PATCH v2] perf/bpf: Fix data races in BPF perf event handling

[Peter Zijlstra <peterz@infradead.org>]

On Thu, Aug 13, 2026 at 11:35:28AM +0530, Deepanshu Kartikey wrote:
> Fix multiple data races involving event->prog field:
> 
> 1. __perf_event_overflow() reads event->prog twice without
>    synchronization creating a TOCTOU race. Fix by using READ_ONCE()
>    to capture prog into a local variable and pass it directly to
>    bpf_overflow_handler() to avoid a second read inside that function.

Well, first you have to show there is concurrency where this matters,
since I still don't believe in your next point.

Also, there's actually worse issues when you consider ->prog and
->bpf_cookie form a pair.

> 2. perf_event_set_bpf_handler() and perf_event_free_bpf_handler()
>    perform plain writes to event->prog without WRITE_ONCE(), failing
>    to pair with the READ_ONCE() in __perf_event_overflow(). Fix by
>    using WRITE_ONCE() in all write paths including
>    perf_event_detach_bpf_prog().

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.

> 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.