Description

FastNetMon is a high-performance DDoS detector and sensor. In version 1.2.9 and earlier, process_sflow_flow_sample() in src/sflow_plugin/sflow_collector.cpp passes the attacker-controlled sflow_raw_protocol_header_t.header_size to parse_raw_packet_to_simple_packet_full() as its trusted captured length without comparing it with the bytes remaining in the record. An inflated header_size creates a false end pointer beyond the received sFlow v5 UDP buffer, defeating the nested parser's bounds checks and causing an unauthenticated remote out-of-bounds read and process crash, with possible limited exposure of adjacent bytes through parsed flow fields. No fixed release is available as of this review.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.2",
  "pubDate": "2026-11-05T23:17:02.633Z",
  "pubdate": "2026-11-05T23:17:02.633Z",
  "executiveSummary": "The vulnerability is an out-of-bounds (OOB) read flaw located within the sFlow packet parsing logic of FastNetMon, specifically affecting versions 1.2.9 and earlier.\nThis issue stems from insufficient input validation of the sflow_raw_protocol_header_t.header_size field, which is trusted by the parsing process without verifying it against the actual boundaries of the received sFlow v5 UDP buffer.\nAn unauthenticated, remote attacker can exploit this by sending a maliciously crafted sFlow packet with an inflated header_size value. This triggers the parser to operate on memory regions beyond the intended buffer bounds.\nThe primary impacts include service instability, leading to a process crash (Denial of Service), and the potential for unauthorized information disclosure, as the parser may interpret adjacent memory bytes as valid flow fields.\nBecause FastNetMon is designed for high-performance network monitoring, it is often exposed to untrusted traffic, significantly increasing the risk. No fixed release is currently available, necessitating the implementation of compensating controls at the network perimeter.",
  "technicalDetails": "The vulnerability exists in src/sflow_plugin/sflow_collector.cpp within the process_sflow_flow_sample() function. The root cause is a trust-based design flaw where the application relies on the header_size metadata provided within an sFlow v5 packet to determine the packet length for downstream processing.\nWhen process_sflow_flow_sample() receives an sFlow sample, it extracts the header_size from the sflow_raw_protocol_header_t structure and passes this value directly to parse_raw_packet_to_simple_packet_full() as the length parameter. The application fails to perform a boundary check comparing this user-supplied length against the actual number of bytes remaining in the allocated UDP buffer.\nThe attack flow initiates when an attacker transmits a crafted UDP sFlow datagram to the collector. The attacker manipulates the header_size field to exceed the actual length of the provided payload. During execution, parse_raw_packet_to_simple_packet_full() utilizes this inflated length to establish the end pointer for subsequent parsing operations.\nBecause the end pointer resides outside the legitimate UDP buffer boundary, the internal nested parser logic—which relies on this pointer to perform its boundary checks—is effectively bypassed. As the parser iterates through the fields based on the corrupted pointer, it accesses memory locations adjacent to the legitimate buffer.\nThis results in an unauthenticated, remote out-of-bounds read. The immediate operational consequence is a memory access violation, leading to a process crash and Denial of Service. Furthermore, since the parser interprets these OOB memory contents as valid flow data, there is a risk of limited information leakage, as sensitive adjacent memory contents might be processed or logged as field values, potentially exposing internal application state or previous data fragments."
}