CVE-2026-89580

In the Linux kernel, the following vulnerability has been resolved:

bpf: Disable preemption in bpf get stack

get perf callchain() returns a per-CPU perf callchain entry buffer and releases its recursion slot via put callchain entry() before returning, so nothing keeps the entry reserved while bpf get stack() consumes it below.

A preemptible BPF program (e.g. a non-sleepable raw tracepoint program on a PREEMPT kernel, which runs under migrate disable() but not preempt disable()) can be scheduled out between obtaining the entry and the copy. Another task scheduled on the same CPU then reuses the same per-CPU buffer and overwrites trace->nr with a larger value. copy len is then computed from the inflated trace->nr and can exceed the caller's buffer, causing an out-of-bounds write in the memcpy() and in the build id path.

The rcu read lock() taken here alone does not prevent this. It is only taken on the may fault path, and under CONFIG PREEMPT RCU it does not disable preemption; it merely keeps perf's callchain buffer array alive (freed via call rcu()) and does nothing to stop another task from reusing the entry.

Disable preemption around obtaining the callchain entry and copying it into the caller's buffer, so the entry cannot be reused underneath us and trace->nr stays bounded by max depth. Build ID resolution may fault and is therefore deferred until after preemption is re-enabled; by then the instruction pointers have already been copied into buf, so it operates only on that private copy. Note, preempt disable() also subsumes the buffer-lifetime guarantee the rcu read lock() provided, since a preempt-disabled section is an RCU read-side critical section for the callchain buffers' call rcu() reclaim.

[ changed Fixes: commit ]