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.
