CVE-2026-6554: 
CBL Mariner vulnerability analysis and mitigation

CVE-2026-6554 is an infinite loop vulnerability in the libpcap BPF (Berkeley Packet Filter) interpreter that allows a local, low-privileged attacker to cause a denial of service by supplying a crafted filter program. The vulnerability was discovered by Kaixuan LI and disclosed on September 5, 2026. It affects libpcap versions prior to 1.10.7, maintained by The Tcpdump Group. The CVSS v3.1 base score is 5.5 (Medium) (GitHub Advisory, Feedly).

The root cause is classified as CWE-835 (Loop with Unreachable Exit Condition / Infinite Loop). The libpcap BPF interpreter in pcapint_filter_with_aux_data() treats the offset field of the ja L (unconditional jump) BPF instruction as a signed integer to support backward jumps for looping constructs (e.g., ip6 protochain), but imposes no limit on the number of such iterations. Programs generated internally by libpcap are safe, but externally supplied filter programs — loaded via pcap_offline_filter() or the deprecated bpf_filter() — can contain a ja L instruction that jumps to itself or to a prior instruction guaranteed to re-execute the same jump, causing the interpreter to spin indefinitely. The fix introduces a hard-coded limit of 64 backward jumps per packet (MAX_BACKWARD_JUMPS 64U) in the interpreter and adds a validator check in pcapint_validate_filter() to reject the immediately detectable case of a self-referencing jump (k == -1) (libpcap commit, GitHub Advisory).

Successful exploitation results in a denial of service through CPU exhaustion: the affected application or service using libpcap hangs indefinitely while the interpreter loops, consuming 100% of a CPU core. There is no impact on confidentiality or data integrity. The scope is limited to the process executing the malicious filter, but services such as tcpdump, Wireshark, or any network monitoring tool relying on libpcap could be rendered unresponsive (Feedly, libpcap commit).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the disclosure date. The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires local access with low privileges and the ability to supply an external BPF filter program to a libpcap-consuming application (Feedly).

1. Identify a target application: Locate a locally accessible service or tool that uses libpcap and accepts externally supplied BPF filter programs (e.g., via pcap_offline_filter() or bpf_filter()), running a version of libpcap prior to 1.10.7.
2. Craft a malicious BPF filter: Construct a BPF filter program containing a ja L instruction with a negative signed offset (k == -1 for a self-jump, or any backward offset that creates an unavoidable loop back to the same instruction).
3. Supply the filter to the target: Pass the crafted filter program to the vulnerable application through any available interface that invokes pcap_offline_filter() or bpf_filter() with externally provided programs.
4. Trigger the infinite loop: Once the interpreter processes the malicious ja L instruction, it enters an infinite loop, consuming CPU resources and hanging the application, resulting in denial of service (libpcap commit, GitHub Advisory).

• Process: A libpcap-consuming process (e.g., tcpdump, dumpcap, custom network tools) showing sustained 100% CPU utilization on a single core with no progress or output.
• Logs: Application logs showing the process stalled or unresponsive after loading an external BPF filter program; absence of expected packet processing output.
• File System: Unexpected or externally provided BPF filter program files supplied to network capture utilities, particularly those containing raw BPF bytecode with backward jump instructions.

Upgrade libpcap to version 1.10.7 or later, which enforces a hard-coded limit of 64 backward jumps per packet and rejects self-referencing ja L instructions during filter validation (libpcap commit). As interim mitigations: restrict local user permissions to prevent untrusted users from supplying BPF filter programs to libpcap-based applications; implement OS-level CPU time limits (e.g., ulimit -t) for processes that execute BPF filters; and validate all externally sourced BPF filter programs before deployment to detect suspicious looping constructs (Feedly).