CVE-2025-29915: Oisf Suricata DOS Vulnerability

CVE-2025-29915 Overview

CVE-2025-29915 affects Suricata, an open-source network Intrusion Detection System (IDS), Intrusion Prevention System (IPS), and Network Security Monitoring engine maintained by the Open Information Security Foundation (OISF). The vulnerability stems from a configuration mismatch between the AF_PACKET defragmentation feature and Suricata's default packet buffer size. When AF_PACKET reassembles fragmented packets before passing them to Suricata, the resulting reassembled packet can exceed the buffer size derived from the network interface Maximum Transmission Unit (MTU). Suricata then processes a truncated view of the traffic, which can allow attackers to evade detection signatures and inspection logic.

Critical Impact

Attackers can craft fragmented network traffic that bypasses Suricata IDS/IPS inspection, undermining the integrity of network detection without triggering alerts.

Affected Products

• OISF Suricata versions prior to 7.0.9
• Deployments using the default AF_PACKET capture method on Linux
• Suricata installations relying on MTU-derived default packet size with defrag enabled

Discovery Timeline

• 2025-04-10 - CVE-2025-29915 published to the National Vulnerability Database (NVD)
• 2025-05-29 - Last updated in NVD database

Technical Details for CVE-2025-29915

Vulnerability Analysis

The vulnerability is classified under [CWE-347] and is rooted in inconsistent defaults between the kernel-level AF_PACKET capture interface and Suricata's user-space packet inspection engine. Suricata uses AF_PACKET as one of its primary packet acquisition methods on Linux. The defrag option for AF_PACKET is enabled by default and instructs the kernel to reassemble IP fragments before delivering them to user space.

When multiple fragments are reassembled, the resulting packet can exceed the interface MTU, commonly 1500 bytes. Suricata's default packet size is derived from that MTU, so the reassembled packet is silently truncated when copied into Suricata's inspection buffer. As a result, the detection engine inspects only the leading bytes of the reassembled flow and misses payload content beyond the truncation boundary.

Root Cause

The root cause is a mismatch between two independent defaults. The AF_PACKET capture layer produces packets larger than the MTU after defragmentation, while Suricata's allocated packet buffer is sized to the MTU. There was no warning to operators when this configuration combination produced truncation, and no event was emitted when a packet was truncated.

Attack Vector

An attacker on the network can send IP-fragmented traffic whose reassembled length exceeds the MTU-derived buffer. Malicious payloads placed in the truncated region pass through the sensor without being matched against signatures, bypassing IDS and IPS rules. The attack requires no authentication and no user interaction.

// Patch excerpt: rules/decoder-events.rules
// Adds a decode event so operators are alerted when AF_PACKET truncates packets
alert pkthdr any any -> any any (msg:"SURICATA packet with too many layers"; decode-event:too_many_layers; classtype:protocol-command-decode; sid:2200116; rev:1;)

# Capture events.
alert pkthdr any any -> any any (msg:"SURICATA AF-PACKET truncated packet"; decode-event:afpacket.trunc_pkt; classtype:protocol-command-decode; sid:2200122; rev:1;)

# next sid is 2200123
// Source: https://github.com/OISF/suricata/commit/d78f2c9a4e2b59f44daeddff098915084493d08d

Detection Methods for CVE-2025-29915

Indicators of Compromise

• Triggers of the new Suricata rule SID 2200122 (SURICATA AF-PACKET truncated packet) introduced in version 7.0.9
• Non-zero counters under the EVE JSON event.afpacket.trunc_pkt field indicating packets dropped at the capture layer
• Unexpected gaps in protocol reconstruction logs (HTTP, TLS, DNS) for flows that contain fragmented IP traffic

Detection Strategies

• Enable Suricata 7.0.9 decode-event rules and alert on decode-event:afpacket.trunc_pkt
• Cross-reference EVE JSON stats output with interface-level fragmentation counters from ip -s link and ethtool -S
• Hunt for fragmented flows where Suricata produced no application-layer logs despite matching network traffic in flow records or NetFlow exports

Monitoring Recommendations

• Forward Suricata EVE JSON, including the new afpacket event object, into a centralized log platform for trend analysis
• Baseline normal fragmentation volumes per sensor and alert on sudden spikes in fragmented or truncated packets
• Validate sensor coverage with periodic synthetic fragmented traffic tests to confirm the IDS sees full reassembled payloads

How to Mitigate CVE-2025-29915

Immediate Actions Required

• Upgrade all Suricata sensors to version 7.0.9 or later, which ships improved defaults and operator warnings
• Audit the af-packet section of suricata.yaml and explicitly set a default-packet-size larger than the maximum expected reassembled packet
• Deploy the updated decoder-events.rules so SID 2200122 is active and surfacing truncation events

Patch Information

The fix is delivered in the upstream commit OISF/suricata d78f2c9 and documented in the OISF GitHub Security Advisory GHSA-7m5c-cqx4-x8mp. Additional engineering context is available in the OISF Redmine task report. Operators should pull Suricata 7.0.9 packages from their distribution or rebuild from the tagged release.

Workarounds

• Set af-packet.defrag to no to disable kernel-side reassembly and rely on Suricata's own defragmentation engine, accepting the performance trade-off
• Increase default-packet-size in suricata.yaml to a value such as 9000 to accommodate reassembled fragments on standard Ethernet links
• Where supported, switch the capture method to AF_XDP or DPDK and validate that packet buffers are sized above the maximum reassembled length

# /etc/suricata/suricata.yaml - mitigation configuration
# 1) Ensure packet buffers are large enough for reassembled fragments
default-packet-size: 9000

# 2) AF_PACKET capture settings
af-packet:
  - interface: eth0
    defrag: yes
    # Match buffer size to the largest expected reassembled packet
    buffer-size: 64535
    use-mmap: yes
    tpacket-v3: yes