CVE-2026-89799

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local

bpf_get_stackid is a tracing BPF helper (kprobe, tracepoint, raw_tp, perf_event, tracing/fentry) reached only after a local bpf(2) PROG_LOAD and attach; kernel CNA guidance classifies BPF as Local, with no network or USB path into this helper.

AC:LAttack complexity, low

The attacker controls both sides of the race: a preemptible raw_tp/tracing program with a small STACK_TRACE map, and a same-CPU get_perf_callchain with larger max_depth that reuses the per-CPU entry after put_callchain_entry(). On PREEMPT kernels (e.g. Android) raw_tp uses migrate_disable only, so pinning and retries make the window reliably hittable.

PR:LPrivileges required, low

Loading the required tracing programs needs CAP_BPF and CAP_PERFMON at bpf_prog_load(), and STACK_TRACE maps need CAP_BPF. Per kernel CNA guidance these are Low because BPF tokens and user namespaces can delegate them to non-init-namespace users, not only real root.

UI:NUser interaction, none

The attacker loads their own BPF program, attaches it to a tracepoint they can fire, and invokes bpf_get_stackid through their own syscalls or pinned threads; no victim mount, file open, or other user action is required.

S:UScope, unchanged

The out-of-bounds write corrupts the stack-map bucket slab inside the same host kernel security authority, enabling local privilege escalation; it does not cross a VM, IOMMU, or other distinct trust boundary.

C:HConfidentiality impact, high

After put_callchain_entry(), a reused per-CPU entry can inflate trace->nr so memcpy/jhash2 and the build-id loop copy kernel instruction pointers past the attacker-sized stack_map_bucket, which is kernel memory corruption that can be turned into an arbitrary read primitive.

I:HIntegrity impact, high

Without a remaining size cap on the reused trace->nr, memcpy into the preallocated stack_map_bucket (sized to a small map value_size) or the bpf_stack_build_id store loop is an attacker-sized kernel heap OOB write, up to PERF_MAX_STACK_DEPTH frames, that can smash adjacent slab and hijack control flow.

A:HAvailability impact, high

The same unbounded heap write past a small stack-map bucket causes a kernel oops or panic even when not fully weaponized, matching CNA guidance that any kernel crash or memory-corrupting OOB write is Availability High.