PT-2026-116863 · Linux · Linux
CVE-2026-98644
·
Published
2026-10-18
·
Updated
2026-10-18
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
bpf: Avoid soft lockup in htab map lookup and delete batch()
htab map lookup and delete batch() has no rescheduling point. The
batch count bounds how many entries are copied out, not how many
buckets are visited, so one BPF MAP LOOKUP BATCH call can walk the
map end to end. The empty-bucket fast path is worse: it stays inside
a single rcu read lock() / bpf disable instrumentation() section for
any run of consecutive empty buckets.
That holds up on small maps, but it falls apart at scale. On a
144-CPU arm64 host running a CONFIG PREEMPT NONE kernel, periodic
BPF MAP LOOKUP BATCH calls against an LRU hash map with 16,777,216
buckets held a CPU inside the batch op for 77+ seconds and triggered
the soft lockup watchdog.
Commit 75134f16e7dd ("bpf: Add schedule points in batch ops") fixed this
same problem in the generic batch ops, but not in this htab-native path,
which every htab-based hash map variant uses for its lookup[ and delete]
batch ops.
Complete that fix here. Leave the critical section after 64 consecutive
empty buckets, call cond resched tasks rcu qs(), and resume at the saved
bucket cursor. No locks are held at that point, and resuming from the
cursor is already the function's behavior for non-empty buckets. Add the
same call to the per-bucket loop after copy to user(), where every lock
has been dropped. cond resched rcu() is not enough here: sleeping with
bpf prog active elevated makes tracing programs on that CPU silently
skip their invocations.
Plain cond resched() is not enough either. It is a no-op under PREEMPT
and PREEMPT LAZY, the only models arm64 and x86 have offered since
commit 7dadeaa6e851 ("sched: Further restrict the preemption modes").
It is also never a Tasks RCU quiescent state, in any model: the
reschedule counts as a preemption. The walking task stays a holdout and
stalls every synchronize rcu tasks() caller, ftrace and BPF trampoline
teardown included, until the syscall returns [1].
cond resched tasks rcu qs() is the usual tool for that [2]. It reports
the quiescent state at each yield and still reschedules as
cond resched() does on PREEMPT NONE and PREEMPT VOLUNTARY kernels.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux