---
id: "CVE-2026-98644"
kind: "vulnerability"
aliases: ["CVE-2026-98644"]
title: "Linux kernel: BPF batch lookup can freeze a CPU on large hash maps"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["bpf", "kernel", "linux", "package", "self-hosted"]
not_affected_if: ["no-bpf-hash-map-batch-use"]
published_at: "2026-10-18T16:17:17+00:00"
first_seen_at: "2026-10-23T21:57:16+00:00"
updated_at: "2026-10-25T05:20:52+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98644", "first_seen_at": "2026-10-23T21:57:16+00:00"}]
---

# Linux kernel: BPF batch lookup can freeze a CPU on large hash maps

A BPF_MAP_LOOKUP_BATCH call on a large hash map could walk the whole map without yielding the CPU, which triggered soft lockup warnings and stalled Tasks RCU waiters. The fix adds periodic rescheduling points to the htab batch lookup path, so a local caller can cause a denial of service but not gain code execution from this flaw as described.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- `uname -r` and compare against the kernel version that carries the upstream fix commit (unknown from sources)
- Check whether the host runs BPF hash map batch operations (`bpftool map` usage) on very large LRU hash maps, unknown from sources

## Fix

- Update the Linux kernel to a release that includes the upstream commit resolving this issue (exact version unknown from sources)

## Timeline

- 2026-10-23T21:57:16+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98644

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_