Description

FastNetMon is a high-performance DDoS detector and sensor. In version 1.2.9 and earlier, FastNetMon's IPv6 top-talkers screen-draw thread in draw_table_ipv6() in src/fastnetmon_logic.cpp iterates ipv6_host_counters.average_speed_map without holding counter_map_mutex while recalculate_speed() inserts new keys and may rehash the same map. The race requires networks_list to include the targeted IPv6 range. It causes confirmed undefined behavior under load; a process crash is plausible but was not observed, so reliable denial of service has not been established. No fixed release is available as of this review.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.9",
  "pubDate": "2026-11-05T23:17:02.110Z",
  "pubdate": "2026-11-05T23:17:02.110Z",
  "executiveSummary": "FastNetMon versions 1.2.9 and earlier contain a race condition vulnerability within the IPv6 top-talkers reporting mechanism, specifically in the draw_table_ipv6() function. The vulnerability arises from unsynchronized access to the ipv6_host_counters.average_speed_map data structure, which is concurrently accessed by both the screen-draw thread and the recalculate_speed() function.\nThis synchronization flaw constitutes a data race, leading to undefined behavior when the map undergoes structural modifications, such as rehashing, during iteration. The vulnerability requires the targeted IPv6 range to be present in the networks_list configuration, effectively limiting the attack surface to monitored subnets.\nWhile the primary impact identified is undefined behavior, there is a plausible risk of process termination leading to a Denial of Service (DoS) of the DDoS detection capabilities. As of the current review, no upstream patch has been released. The vulnerability poses a risk to network observability by potentially destabilizing the monitoring daemon during periods of high traffic load.",
  "technicalDetails": "The root cause of this vulnerability is a lack of thread synchronization when accessing a shared memory resource in src/fastnetmon_logic.cpp. The function draw_table_ipv6() iterates over the ipv6_host_counters.average_speed_map to generate the top-talkers interface display. Concurrently, the recalculate_speed() function performs write operations on the same map, including the insertion of new keys. Because the critical section in draw_table_ipv6() fails to acquire the counter_map_mutex, the iterator in the screen-draw thread can become invalidated if the recalculate_speed() function triggers a rehash of the map's underlying container.\nThe attack flow is contingent upon the operational state of the FastNetMon instance. An attacker can influence this by generating specific traffic patterns that force the recalculate_speed() thread to perform high-frequency map mutations. When the map's capacity is exceeded or thresholds are met, the container resizes and reallocates memory. If the draw_table_ipv6() thread is mid-iteration when this memory reallocation occurs, it will attempt to access deallocated memory or follow a dangling pointer, resulting in undefined behavior. This behavior is highly load-dependent, requiring sufficient traffic to force continuous map updates.\nThe vulnerability affects FastNetMon versions 1.2.9 and earlier. Exploitation does not require authentication, but it does require that the targeted IPv6 range is explicitly defined in the networks_list, ensuring that the victim's traffic is actively processed by the vulnerable logic. The technical impact is limited to the potential crash of the FastNetMon process. Should the process terminate, the monitoring system ceases to detect and mitigate DDoS attacks, effectively neutralizing the security posture of the network segment it is protecting. Post-exploitation, the service must be manually restarted to regain functionality, as there is no mention of automated recovery mechanisms in the context of this specific race condition. There are currently no privilege requirements for exploitation, as the race condition is triggered by legitimate (albeit potentially malicious) network traffic that the application is designed to ingest and analyze. Given that the crash is non-deterministic, the reliability of a sustained DoS attack is low, but the potential for periodic service disruption remains a significant concern for high-availability security infrastructure."
}