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 ]