CVE-2026-25061: 
NixOS vulnerability analysis and mitigation

CVE-2026-25061 is an out-of-bounds write vulnerability in the wifipcap component of tcpflow, a TCP/IP packet demultiplexer. Affecting all versions up to and including 1.6.1, the flaw exists in the TIM (Traffic Indication Map) element handler within WifiPacket::parse_elements(), where a length check is performed on the wrong field, allowing a crafted 802.11 management frame to trigger a 1-byte out-of-bounds write past tim.bitmap[251]. The vulnerability was published on January 29, 2026, with the GitHub Security Advisory (GHSA-q5q6-frrv-9rj6) released the same day. It carries a CVSS v3.1 base score of 7.5 (High) and a CVSS v4.0 base score of 5.5 (Medium) (GitHub Advisory, Red Hat Bugzilla).

The root cause is an out-of-bounds write (CWE-787) in src/wifipcap/wifipcap.cpp at lines 606–614. The parse_elements() function handles the TIM element by checking pbody->rates.length (instead of pbody->tim.length) against sizeof(pbody->tim.bitmap) before performing a memcpy into the 251-byte tim.bitmap array. Since tim.length is a uint8_t with a maximum value of 255, the copy size (tim.length - 3) can reach 252 bytes — one byte beyond the 251-byte buffer. An attacker can exploit this by crafting a malicious 802.11 beacon frame with tim.length = 255 and a small/empty rates element (so the incorrect guard check passes), delivered as a pcap file or live wireless packet processed by tcpflow. The affected mgmt_body_t structure is stack-allocated in handle_beacon() and related handlers, making stack corruption the mechanism of impact (GitHub Advisory).

The primary confirmed impact is denial of service (DoS) via application crash due to stack corruption from the 1-byte out-of-bounds write. While the overflow is small, the stack-allocated nature of the affected structure leaves open the theoretical possibility of code execution, though this has not been demonstrated and is considered unlikely. The vulnerability affects non-Windows platforms only, as wifipcap is not compiled on Windows. No confidentiality or integrity impact is currently assessed (GitHub Advisory, Red Hat Bugzilla).

A proof-of-concept (PoC) is publicly available in the GitHub Security Advisory, including both a standalone C simulation demonstrating the 1-byte overflow using a canary and a Python script that generates a malicious beacon pcap file. The CVSS v4.0 exploit maturity is rated PROOF_OF_CONCEPT. No in-the-wild exploitation has been reported, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.07%, indicating low probability of near-term exploitation. No threat actor attribution is known (GitHub Advisory).

1. Craft a malicious beacon pcap: Use the published Python PoC script to generate a pcap file containing an 802.11 beacon frame with tim.length = 255 and a minimal/empty rates element (e.g., rates.length = 0), ensuring the incorrect guard check (rates.length > sizeof(tim.bitmap)) evaluates to false.
2. Deliver the malicious frame: Supply the crafted pcap to a vulnerable tcpflow instance via the -r flag (e.g., tcpflow -r malicious_beacon.pcap), or transmit the crafted 802.11 frame over a wireless network being monitored by tcpflow in live capture mode.
3. Trigger the vulnerable code path: tcpflow's wifipcap component parses the beacon frame, enters the E_TIM case in parse_elements(), passes the incorrect bounds check (checking rates.length instead of tim.length), and executes memcpy(pbody->tim.bitmap, p + offset, 252) — writing 252 bytes into a 251-byte stack buffer.
4. Achieve DoS: The 1-byte stack overflow corrupts adjacent stack memory in handle_beacon(), causing a crash (segmentation fault or stack smashing detected by compiler mitigations), resulting in denial of service of the tcpflow process (GitHub Advisory).

• Process: Unexpected crash or segmentation fault of the tcpflow process; stack smashing detection messages (e.g., *** stack smashing detected ***) in system logs when tcpflow is compiled with -fstack-protector.
• Logs: System logs (e.g., /var/log/syslog, journalctl) showing tcpflow process termination with signal 11 (SIGSEGV) or signal 6 (SIGABRT) after processing 802.11 traffic.
• Network: Unusual 802.11 beacon frames with TIM element length field set to 255 (0xFF) and minimal or empty supported rates elements, observable in wireless packet captures.
• File System: Presence of crafted pcap files with anomalous 802.11 beacon frames (TIM IE with length byte = 0xFF) submitted to tcpflow for processing (GitHub Advisory).

As of the original publication date (January 29, 2026), no official patch was available. However, Debian LTS issued an advisory (DLA-4478-1) and Fedora subsequently released updated packages addressing this vulnerability, as reflected in downstream Linux distribution updates. The correct fix is to replace the erroneous bounds check if (pbody->rates.length > sizeof pbody->tim.bitmap) with if ((pbody->tim.length - 3) > sizeof pbody->tim.bitmap) in wifipcap.cpp. As interim mitigations: restrict tcpflow to processing only trusted pcap files, avoid live 802.11 capture in untrusted wireless environments, and consider disabling wifipcap-based processing if 802.11 analysis is not required. Users should upgrade to patched distribution packages as they become available (GitHub Advisory, Red Hat Bugzilla).

Red Hat tracked the vulnerability via Bugzilla with a medium severity rating, and the issue was picked up by downstream distributions including Debian LTS (DLA-4478-1) and Fedora. Tenable added detection plugins (Nessus plugin IDs 297265 and 298570) for the vulnerability. German security outlet Pro-Linux.de covered the issue, noting the potential for arbitrary command execution. Community reaction has been relatively muted given the limited scope and low EPSS score (Red Hat Bugzilla, GitHub Advisory).