CVE-2026-6554: libpcap BPF Interpreter DOS Vulnerability

CVE-2026-6554 Overview

CVE-2026-6554 is a denial-of-service vulnerability in the libpcap Berkeley Packet Filter (BPF) interpreter. The interpreter treats the offset in the ja L (jump always) BPF instruction as a signed integer to enable looping via backward jumps. However, it does not cap the number of loop iterations. A crafted BPF filter program can force pcap_offline_filter() into an infinite loop, exhausting CPU resources.

The flaw is tracked as CWE-835: Loop with Unreachable Exit Condition. Exploitation requires local access and the ability to supply a filter program to a libpcap consumer, limiting the practical attack surface.

Critical Impact
A malicious BPF filter passed to pcap_offline_filter() can hang the calling process indefinitely, causing availability loss for packet-processing services.

Affected Products

libpcap (the-tcpdump-group) userland BPF interpreter
Applications linking libpcap and invoking pcap_offline_filter() with untrusted filter programs
Downstream tools and distributions bundling vulnerable libpcap versions

Discovery Timeline

2026-09-05 - CVE-2026-6554 published to NVD
2026-09-08 - Last updated in NVD database

Technical Details for CVE-2026-6554

Vulnerability Analysis

The libpcap userland BPF interpreter supports filter programs that can exceed the kernel BPF_MAXINSNS limit of 512 or 4096 instructions. To enable loop constructs, the interpreter interprets the offset in the ja L opcode as a signed integer, permitting backward jumps. The interpreter did not enforce a maximum iteration count on these backward jumps.

An attacker who can supply a filter program crafted with a backward-jumping ja instruction that never satisfies an exit condition drives the interpreter into an unbounded loop. The calling thread consumes CPU indefinitely, denying service to legitimate packet processing. The impact is confined to availability; confidentiality and integrity are not affected.

Root Cause

The interpreter in bpf_filter.c accepts arbitrary backward jump offsets without tracking or limiting the number of backward transitions during execution. The upstream fix introduces a MAX_BACKWARD_JUMPS cap of 64, terminating filter execution when the threshold is exceeded.

Attack Vector

Exploitation requires local access with low privileges. The attacker must control or influence the BPF filter program passed to pcap_offline_filter(). This scenario is uncommon because most libpcap consumers compile filters from trusted operator input rather than untrusted sources. Applications that accept externally supplied precompiled BPF programs are the primary risk surface.

#include <linux/filter.h>
#endif

+#define MAX_BACKWARD_JUMPS 64U
+
/*
 * Kernel BPF implementations tend to define BPF_MAXINSNS to 512 or 4096, the
 * userland interpreter in libpcap is meant to support much longer filter

Source: GitHub libpcap Commit ff3c834

Detection Methods for CVE-2026-6554

Indicators of Compromise

Processes linking libpcap exhibiting sustained 100% CPU utilization on a single thread with no packet throughput
Unresponsive tcpdump, Wireshark, or other pcap-consuming tools when loading a specific capture or filter file
Watchdog-triggered restarts of network analysis daemons that ingest externally supplied BPF programs

Detection Strategies

Inventory installed libpcap versions across Linux, macOS, and BSD hosts and correlate against the patched release
Audit applications that expose pcap_offline_filter() to attacker-influenced filter input
Review process telemetry for long-running libpcap consumers with anomalous CPU-bound behavior

Monitoring Recommendations

Alert on per-process CPU saturation lasting beyond expected filter runtimes for pcap-based tools
Track invocations of packet-analysis utilities against untrusted .pcap or filter files
Log and review BPF filter program sources ingested by multi-user or service-mode packet processors

How to Mitigate CVE-2026-6554

Immediate Actions Required

Upgrade libpcap to the version containing commit ff3c834 or later once distributed by your vendor
Restrict which users and services can submit BPF filter programs to pcap-consuming applications
Enforce CPU-time resource limits (ulimit -t, cgroup cpu.max) on processes that parse untrusted filters

Patch Information

The upstream fix is available in the-tcpdump-group/libpcap via commit ff3c83475ac303c6b681c52ad0b6e14795a8e0ce. The patch introduces #define MAX_BACKWARD_JUMPS 64U in bpf_filter.c and terminates filter execution once the threshold is reached. Rebuild and redeploy any statically linked consumers after applying the update.

Workarounds

Reject or sandbox BPF filter programs received from untrusted sources until libpcap is patched
Run pcap-consuming services under process-level CPU quotas to bound runaway execution
Use a wrapper that validates filter programs against known-safe patterns before passing them to pcap_offline_filter()

bash

# Apply a CPU-time cap to processes invoking libpcap filters
systemd-run --scope -p CPUQuota=50% -p RuntimeMaxSec=30 \
  tcpdump -r suspicious.pcap -F untrusted.bpf