CVE-2026-89991: bpf: Fix infinite loop in pcpu_freelist push with one possible CPU
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix infinite loop in pcpufreelist push with one possible CPU
pcpufreelistpush() can loop forever when only one CPU is possible and an NMI re-enters pcpufreelistpush() while the interrupted context holds that CPU's freelist lock.
After the current-CPU fast path fails, the fallback loop walks cpupossiblemask while skipping the current CPU. With CONFIGSMP=n, or when an SMP kernel is limited to one possible CPU with nrcpus=1 or possiblecpus=1, there are no other possible CPUs to examine. The loop therefore makes no lock acquisition attempt and can never make progress.
The following stack was observed on a UP system:
NMI context: pcpufreelistpush freehtabelem htabmapdeleteelem [perf-event BPF program] perfeventoverflow perfeventnmihandler excnmi
Interrupted context: pcpufreelistpush pcpufreelistpush freehtabelem htabmapdeleteelem [rawtp/sysenter BPF program] bpftracesysenter dosyscall64
rawresspinlock() detects the same-CPU recursive acquisition and returns -EDEADLK, but the subsequent fallback loop has no candidate head on a system with one possible CPU.
Restore the extra fallback head that existed before the rqspinlock conversion. Keep the current-CPU fast path, then try the other possible CPUs and finally the extra head. The additional head lets a push, which cannot fail without losing a preallocated element, make progress when the only per-CPU head is held by the interrupted context.
Also check the extra head from the pop path so that nodes placed there can be reused.
Affected Software
Event History
Frequently Asked Questions
Which systems are affected by the infinite-loop condition?
The condition applies when the kernel has only one possible CPU: a non-SMP build with CONFIG_SMP=n, or an SMP kernel constrained with nr_cpus=1 or possible_cpus=1.
What must happen to trigger the hang?
An NMI must re-enter pcpu_freelist_push() while an interrupted context already holds that CPU's freelist lock. The described observed path involved BPF map-element deletion from both a perf-event BPF program in NMI context and a raw tracepoint BPF program in the interrupted context.
How can an administrator identify the relevant exposure?
Check whether the running system is configured with only one possible CPU, including through nr_cpus=1 or possible_cpus=1 boot limits. The reported failure manifests as an NMI-context path into pcpu_freelist_push() while the interrupted task is also deleting a BPF hash-table map element.