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.
Published: 2026-10-18
Score: 4.4 Medium
EPSS: < 1% Very Low
KEV: No
Impact: Soft lockup leading to denial of service
Action: Immediate Patch
AI Analysis

Impact

The flaw lies in the kernel’s __htab_map_lookup_and_delete_batch function, which contains no rescheduling points during batch lookup and delete operations. When a BPF_MAP_LOOKUP_BATCH call scans a very large htab-based hash map, the routine can run uninterrupted for many seconds, causing a CPU soft lockup and triggering the watchdog. This vulnerability is cataloged as CWE-1050, reflecting the improper handling of complex data structures and failure to provide a scheduling point during a long-running kernel operation.

Affected Systems

The affected systems are any Linux kernel builds that include the unpatched htab‑based hash map code. All distributions shipping a kernel prior to the patch that added periodic rescheduling in this function are vulnerable. No specific vendor version list is provided, so any kernel that has not yet incorporated the corresponding commit is at risk.

Risk and Exploitability

According to the current scoring, the CVSS score for this issue is 4.4 and the EPSS score is < 1%, indicating a low likelihood of exploitation in public settings and a low overall severity. The vulnerability is not listed in the CISA KEV catalog. The attack surface is limited; the likely attack vector is loading a malicious BPF program or invoking a large BPF_MAP_LOOKUP_BATCH call against a htab‑based hash map. This scenario is inferred from the description because explicit prerequisites are not listed. When that privilege is present, an attacker could drive a high‑volume lookup batch, causing a soft lockup that lasts several minutes and triggers the watchdog, resulting in a denial of service. The impact is confined to the kernel of affected nodes and would affect any running process on the locked CPU.

Generated by OpenCVE AI on October 23, 2026 at 06:32 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Upgrade the kernel to a version that includes the patch that adds rescheduling points to __htab_map_lookup_and_delete_batch
  • If the upgrade cannot be applied immediately, limit the size of BPF hash maps or reduce the batch size of BPF_MAP_LOOKUP_BATCH calls to avoid long walks through the table
  • Consider disabling PREEMPT_NONE or enabling a preemptive scheduler model so that long operations are more likely to yield

Generated by OpenCVE AI on October 23, 2026 at 06:32 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DLA Debian DLA DLA-4850-1 linux-6.12 security update
Ubuntu USN Ubuntu USN USN-8961-1 Linux kernel vulnerabilities
History

Fri, 23 Oct 2026 00:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-12

Thu, 22 Oct 2026 12:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-1050
References
Metrics threat_severity

None

 cvssV3_1

{'score': 4.4, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Moderate

Sun, 18 Oct 2026 19:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-12

Sun, 18 Oct 2026 15:30:00 +0000

Type Values Removed Values Added
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.
Title bpf: Avoid soft lockup in __htab_map_lookup_and_delete_batch()
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-10-19T09:23:13.963Z

Reserved: 2026-09-25T10:25:14.362Z

Link: CVE-2026-98644

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-10-18T16:17:17.623

Modified: 2026-10-19T10:19:28.723

Link: CVE-2026-98644

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-10-18T00:00:00Z

Links: CVE-2026-98644 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-10-23T06:45:07Z

Weaknesses
  • CWE-1050

    Excessive Platform Resource Consumption within a Loop