BPF stack helpers race fixed with preemption disable

Kernel BPF maintainers have merged a fix that closes a preemption race in the stack map helpers, stopping an out-of-bounds write that could hit any program using bpf_get_stack or bpf_get_stackid on a preemptible kernel.

The helpers fetch a stack trace through get_perf_callchain, which hands back a per-CPU callchain buffer and immediately releases its recursion slot. Nothing then kept that buffer reserved while the helper copied instruction pointers into the caller-supplied buffer or stack-map bucket. On a PREEMPT kernel, a non-sleepable BPF program (for example a raw tracepoint running only under migrate_disable) could be scheduled out in that window. Another task on the same CPU would reuse the entry, overwrite the recorded frame count with a larger value, and cause the subsequent copy or build-id path to write past the end of the caller's buffer.

RCU read-side locking alone did not close the hole: it is taken only on the faultable path, and under CONFIG_PREEMPT_RCU it does not disable preemption, so it cannot stop reuse of the per-CPU entry.

Jiri Olsa refactored the stackid and callchain paths so the critical section is narrow and structured, then applied preemption disable around obtain-and-copy for bpf_get_stackid. Daniel Borkmann supplied the matching change for bpf_get_stack, deferring build-id resolution (which may fault) until after preemption is re-enabled and the IPs already sit in a private buffer. The work builds on an earlier report from Tao Chen that had gone without follow-up since February; the fixes are marked for stable.

A related cleanup ensures task-stack helpers zero the output buffer on every error path, so uninitialized memory is not left as a map key. The series is in bpf-next.