CVE-2026-89580
massPreemption race in Linux kernel BPF __bpf_get_stack causes local out-of-bounds write
The Linux kernel's BPF stack-capture path __bpf_get_stack() consumes a per-CPU perf callchain buffer without disabling preemption, so on a preemptible (PREEMPT) kernel a BPF program can be scheduled out between obtaining the entry and copying it, letting another task on the same CPU reuse and overwrite the buffer with a larger trace->nr. copy_len is then computed from the inflated count and can exceed the caller's buffer, producing an out-of-bounds write in the memcpy() and in the build_id resolution path. Exploitation requires local access with the ability to run a preemptible BPF program (e.g., a non-sleepable raw tracepoint program) plus a racing task on the same CPU, and yields kernel memory corruption with high confidentiality, integrity, and availability impact (CVSS 7.8), a plausible privilege-escalation primitive. Any system running an affected kernel built with CONFIG_PREEMPT where the attacker can load BPF programs is exposed; the fix disables preemption around obtaining the callchain entry and copying it, deferring may-fault build_id work to a private copy. No public proof of concept exists, no exploitation in the wild has been reported, and the CVE is not in CISA's KEV.
What to do: Apply your distribution's kernel update once the fix (preempt_disable around callchain acquisition and copy in __bpf_get_stack) is backported to your stable branch, then reboot. As an interim mitigation, disable unprivileged BPF (kernel.unprivileged_bpf_disabled=1) and restrict which local users can attach BPF programs. Check whether your kernels are built with CONFIG_PREEMPT and monitor vendor advisories for the exact patched version ranges.
| Linux kernel (BPF subsystem, __bpf_get_stack) | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
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 ]
- Vector
- CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
In the news0 stories
No ingested article mentions this CVE yet.