Suricata

Summary¶

Suricata's HTTP SWF decompression path can trigger a heap buffer overflow when
swf-decompression.decompress-depth is configured to a uint32_t value that
wraps after the internal SWF header adjustment. An ASAN-enabled build aborts in
FileSwfDecompression() with a 4 GiB zero-fill write.

Affected code¶

Confirmed on Suricata 9.0.0-dev, commit 0eda09f302 from 2026-06-03, built
with ASAN.

Relevant files:

• src/util-file-decompression.c
• src/detect-file-data.c

The vulnerable path is reached from HTTP to-client file_data inspection when
SWF decompression is enabled:

• FiledataGetDataCallback() calls FileSwfDecompression() for HTTP1
  to-client file data if htp_state->cfg->swf_decompression_enabled is true
  and the file data starts with a compressed SWF signature.
• FileSwfDecompression() computes decompressed_data_len from the configured
  decompress_depth, then unconditionally adds 8 bytes for the generated FWS
  header.

Root cause¶

In FileSwfDecompression():

uint32_t decompressed_data_len =
    (decompress_depth == 0) ? decompressed_swf_len : decompress_depth;
decompressed_data_len += 8;

SCInspectionBufferCheckAndExpand(out_buffer, decompressed_data_len);
...
out_buffer->len = decompressed_data_len;
...
memset(out_buffer->buf + 8, 0, decompressed_data_len - 8);

With decompress-depth=4294967295, decompressed_data_len += 8 wraps to 7.
The inspection buffer is only expanded to the default 4096-byte allocation, but
the later memset(out_buffer->buf + 8, 0, decompressed_data_len - 8) underflows
the length argument to 4294967295 and writes zeros past the heap allocation.

Reproducer¶

The full reproducer will be provided in a suricata-verify test submitted
separately. That test includes a pcap with a single HTTP transaction returning a
small zlib-compressed CWS SWF file, plus a file_data rule that reaches the
HTTP file-data inspection path.

After the suricata-verify test is submitted, run from a Suricata ASAN build
using the pcap from that test:

ASAN_OPTIONS=abort_on_error=1:detect_leaks=0 \
src/suricata \
  -c suricata.yaml \
  -S <suricata-verify-test>/test.rules \
  -r <suricata-verify-test>/input.pcap \
  -l /tmp/suri-swf-depth-wrap \
  --runmode single \
  -k none \
  --set app-layer.protocols.http.libhtp.default-config.swf-decompression.enabled=yes \
  --set app-layer.protocols.http.libhtp.default-config.swf-decompression.decompress-depth=4294967295

Observed result¶

Suricata aborts with ASAN:

ERROR: AddressSanitizer: heap-buffer-overflow
WRITE of size 4294967295
    #1 FileSwfDecompression src/util-file-decompression.c:149
    #2 FiledataGetDataCallback src/detect-file-data.c:456

0 bytes after 4096-byte region allocated by:
    #2 SCInspectionBufferCheckAndExpand src/detect-engine-inspect-buffer.c:227
    #3 FileSwfDecompression src/util-file-decompression.c:132

Expected result¶

Suricata should not perform an out-of-bounds write or abort when processing the
traffic under this configuration.

Impact¶

This is config-dependent. A packet alone is not sufficient; the vulnerable path
requires:

• HTTP SWF decompression enabled.
• A rule or other detection path that inspects HTTP to-client file_data.
• A wrapping swf-decompression.decompress-depth value.

The demonstrated impact is denial of service / memory safety violation. No
credible RCE path was identified from this primitive: the overwrite is a huge
zero-fill, the byte value is fixed, and the size is controlled by configuration
rather than packet contents.

Validation¶

• With decompress-depth=4294967295, the ASAN build aborts with exit 134.
• With normal SWF decompression depth, the same pcap and rule complete cleanly
  and emit one file_data alert, confirming reachability of the SWF
  decompression path.
• A suricata-verify regression test has been prepared
  and will be submitted separately.

Found by GPT 5.5 using Codex.