CVE-2026-98644: Linux Kernel BPF Hash Map DoS Vulnerability

CVE-2026-98644 Overview

CVE-2026-98644 is a Linux kernel vulnerability in the Berkeley Packet Filter (BPF) subsystem. The function __htab_map_lookup_and_delete_batch() lacks a rescheduling point, allowing a single BPF_MAP_LOOKUP_BATCH syscall to monopolize a CPU while walking large hash maps. On a 144-CPU arm64 host running a CONFIG_PREEMPT_NONE kernel, periodic batch calls against an LRU hash map with 16,777,216 buckets held a CPU for 77+ seconds and triggered the soft lockup watchdog. The empty-bucket fast path compounds the issue by remaining inside a single rcu_read_lock() and bpf_disable_instrumentation() section across consecutive empty buckets.

Critical Impact
A local user with permission to issue BPF batch operations can stall a CPU core, trigger the soft lockup watchdog, and delay RCU Tasks grace periods used by ftrace and BPF trampoline teardown.

Affected Products

Linux kernel versions containing the htab-native batch lookup path
Distributions shipping CONFIG_PREEMPT_NONE or CONFIG_PREEMPT_VOLUNTARY kernels
Workloads using LRU hash maps or other htab-based BPF map variants with large bucket counts

Discovery Timeline

2026-10-18 - CVE-2026-98644 published to the National Vulnerability Database
2026-10-19 - Last updated in NVD database

Technical Details for CVE-2026-98644

Vulnerability Analysis

The vulnerability is a kernel-level denial of service caused by a missing scheduling point in a long-running syscall path. __htab_map_lookup_and_delete_batch() is shared by every htab-based BPF hash map variant for its lookup[_and_delete] batch operations. The batch count argument bounds the number of entries copied to userspace, not the number of buckets traversed. A caller can therefore request a small batch while forcing the kernel to walk the entire map in one invocation.

The empty-bucket fast path is more problematic. The function holds rcu_read_lock() and bpf_disable_instrumentation() across any run of consecutive empty buckets. On very large maps, this critical section can span millions of buckets without yielding. The result is a CPU stall long enough to trigger the kernel soft lockup watchdog.

A prior fix, commit 75134f16e7dd ("bpf: Add schedule points in batch ops"), addressed the same class of issue in the generic batch ops path but did not cover the htab-native path.

Root Cause

The root cause is the absence of a quiescent-state yield inside the per-bucket loop. Plain cond_resched() is a no-op under PREEMPT and PREEMPT_LAZY, and it never counts as a Tasks RCU quiescent state because the yield is treated as a preemption. The walking task remains a Tasks RCU holdout and stalls every synchronize_rcu_tasks() caller, including ftrace and BPF trampoline teardown, until the syscall returns. cond_resched_rcu() is also insufficient because sleeping while bpf_prog_active is elevated silently skips tracing program invocations on that CPU.

Attack Vector

The attack vector is local. A process with the capability to issue BPF_MAP_LOOKUP_BATCH on a large htab-based map can trigger the condition. No remote network access is involved. Impact is confined to availability: watchdog-triggered lockup messages, stalled RCU Tasks grace periods, and delayed tracing or trampoline teardown operations.

See the upstream fix in Kernel Commit 44f9bcb and related backports for the exact code changes.

Detection Methods for CVE-2026-98644

Indicators of Compromise

Kernel log entries reporting soft lockup - CPU#N stuck for Ns! originating from __htab_map_lookup_and_delete_batch or htab_map_lookup_batch call stacks.
RCU Tasks stall warnings referencing a holdout task actively executing a BPF syscall.
Unexpected delays or hangs in ftrace or BPF trampoline attach/detach operations.

Detection Strategies

Monitor /var/log/kern.log and dmesg for soft lockup backtraces that include BPF batch lookup symbols.
Audit BPF syscall usage with bpftrace or audit rules targeting BPF_MAP_LOOKUP_BATCH and BPF_MAP_LOOKUP_AND_DELETE_BATCH commands.
Track processes with CAP_BPF or CAP_SYS_ADMIN that interact with large LRU or htab hash maps.

Monitoring Recommendations

Alert on sustained single-CPU utilization at 100% in kernel mode coinciding with BPF syscall activity.
Collect telemetry on BPF map sizes and flag maps with bucket counts above one million for review.
Correlate soft lockup events with the invoking process, UID, and container context to identify abusive workloads.

How to Mitigate CVE-2026-98644

Immediate Actions Required

Apply the upstream Linux kernel patches referenced below as soon as vendor-signed builds are available.
Restrict BPF syscall access to trusted administrative accounts and audit existing grants of CAP_BPF and CAP_SYS_ADMIN.
Inventory BPF hash maps in production and reduce bucket counts where operationally feasible.

Patch Information

The fix leaves the critical section after 64 consecutive empty buckets, calls cond_resched_tasks_rcu_qs(), and resumes at the saved bucket cursor. The same call is added to the per-bucket loop after copy_to_user(), where all locks have been dropped. Patches are available in the following upstream commits: Kernel Commit 44f9bcb, Kernel Commit 4e48fe9, Kernel Commit 5c8b186, Kernel Commit 77a3b52, Kernel Commit 85136bf, Kernel Commit ca5bd55, and Kernel Commit f0c09de.

Workarounds

Limit the maximum number of buckets provisioned in htab-based BPF maps on affected hosts.
Avoid periodic full-map scans using BPF_MAP_LOOKUP_BATCH against large LRU hash maps until patches are deployed.
Where supported, switch kernels to CONFIG_PREEMPT_FULL to reduce lockup duration, understanding this does not fully resolve the Tasks RCU holdout condition.

bash

# Verify running kernel version and preemption model
uname -r
grep -E 'PREEMPT' /boot/config-$(uname -r)

# List processes holding CAP_BPF or CAP_SYS_ADMIN
getpcaps $(pgrep -d' ' .) 2>/dev/null | grep -E 'cap_bpf|cap_sys_admin'

# Enumerate loaded BPF maps and their sizes
bpftool map show