CVE-2026-98644: bpf: Avoid soft lockup in __htab_map_lookup_and_delete_batch()
In the Linux kernel, the following vulnerability has been resolved:
bpf: Avoid soft lockup in htabmaplookupanddeletebatch()
htabmaplookupanddeletebatch() has no rescheduling point. The batch count bounds how many entries are copied out, not how many buckets are visited, so one BPFMAPLOOKUPBATCH call can walk the map end to end. The empty-bucket fast path is worse: it stays inside a single rcureadlock() / bpfdisableinstrumentation() 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 CONFIGPREEMPTNONE kernel, periodic BPFMAPLOOKUPBATCH 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[anddelete] batch ops.
Complete that fix here. Leave the critical section after 64 consecutive empty buckets, call condreschedtasksrcuqs(), 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 copytouser(), where every lock has been dropped. condreschedrcu() is not enough here: sleeping with bpfprogactive elevated makes tracing programs on that CPU silently skip their invocations.
Plain condresched() is not enough either. It is a no-op under PREEMPT and PREEMPTLAZY, 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 synchronizercutasks() caller, ftrace and BPF trampoline teardown included, until the syscall returns [1]. condreschedtasksrcuqs() is the usual tool for that [2]. It reports the quiescent state at each yield and still reschedules as condresched() does on PREEMPTNONE and PREEMPTVOLUNTARY kernels.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernelto a version that resolves this vulnerability.Patch 75134f16e7dd
Event History
Frequently Asked Questions
Which BPF map operations are affected?
The issue is in lookup-batch and lookup-and-delete-batch operations for htab-based hash map variants. The htab-native path is used by every htab-based hash map variant for these operations.
Does using a small batch count prevent the long CPU stall?
No. The batch count limits the number of entries copied out, not the number of hash buckets visited, so a single call can still scan the entire map.
What conditions make the problem most likely to be visible?
Large maps with long runs of empty buckets are especially problematic, because the empty-bucket path can remain in one RCU read-side and instrumentation-disabled section. The reported reproduction involved periodic batch lookups on a 16,777,216-bucket LRU hash map on a 144-CPU arm64 host running CONFIG_PREEMPT_NONE.
What can be done before applying the fix?
Avoid or reduce use of BPF_MAP_LOOKUP_BATCH and lookup-and-delete batch operations against large htab-based hash maps, particularly where repeated calls may scan sparse maps. Reducing only the requested batch count does not address the bucket-walk behavior.