CVE-2026-98644
Received Received - Intake

Kernel Soft Lockup in Linux BPF Hash Map Batch Operations

Publication date: 2026-10-18

Last updated on: 2026-10-18

Assigner: kernel.org

Description
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.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-10-18
Last Modified
2026-10-18
Generated
2026-10-18
AI Q&A
2026-10-18
EPSS Evaluated
N/A
NVD
CVE-2026-98644
EUVD
EUVD-2026-103558

Affected Vendors & Products

Showing 8 associated CPEs
Vendor Product Version / Range
Linux Linux 057996380a42bb64ccc04383cfa9c0ace4ea11f0
Linux Linux 057996380a42bb64ccc04383cfa9c0ace4ea11f0
Linux Linux 057996380a42bb64ccc04383cfa9c0ace4ea11f0
Linux Linux 057996380a42bb64ccc04383cfa9c0ace4ea11f0
Linux Linux 057996380a42bb64ccc04383cfa9c0ace4ea11f0
Linux Linux 057996380a42bb64ccc04383cfa9c0ace4ea11f0
Linux Linux 057996380a42bb64ccc04383cfa9c0ace4ea11f0
Linux Linux 5.6

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

This is a soft lockup vulnerability in the Linux kernel's BPF (Berkeley Packet Filter) subsystem. The issue occurs in the __htab_map_lookup_and_delete_batch() function, which lacks rescheduling points during batch operations. When processing large hash maps, the function can hold a CPU for extended periods without yielding, triggering the kernel's soft lockup watchdog after 77+ seconds on a 144-CPU system.

Detection Guidance

This vulnerability is specific to the Linux kernel's BPF implementation and may not have direct network detection methods. Monitor for soft lockup warnings in kernel logs using commands like 'dmesg | grep -i lockup' or 'journalctl -k | grep -i lockup'. Check for high CPU usage in BPF-related processes with 'top -H -p $(pgrep -f bpf)'.

Impact Analysis

This vulnerability can cause system unresponsiveness or crashes during BPF operations on large hash maps. It may lead to degraded performance, application timeouts, or system hangs, particularly on high-CPU systems running BPF programs that interact with large datasets.

Mitigation Strategies

Apply the kernel patch that resolves this issue by updating to a fixed Linux kernel version. If immediate patching is not possible, consider disabling BPF_MAP_LOOKUP_BATCH operations temporarily or limit their usage until the patch is applied.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-98644. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart