Project

General

Profile

Actions

Bug #8887

open
JL JL

detect/flowvar: capture buffers leak when the var store fails to allocate

Bug #8887: detect/flowvar: capture buffers leak when the var store fails to allocate

Added by Jeff Lucovsky 7 days ago.

Status:
New
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

`DetectVarStoreMatch` and `DetectVarStoreMatchKeyValue` in `src/detect-flowvar.c` return 1 when the `DetectVarList` allocation fails, leaving the buffers the caller passed in allocated. Both call sites, in `DetectPcrePayloadMatch`, discard the return value with a `(void)` cast, so the capture buffer - and the key, for the key/value form -- is lost whenever that allocation fails.

`DetectFlowvarPostMatch` chains three conditions with no closing else and frees the list node at the end of the iteration either way, so an entry matching none of the three would keep its buffer after the node holding the pointer is gone. No caller can build such an entry today: `DETECT_VAR_TYPE_FLOW_POSTMATCH` is stored only for a packet that has a flow, `DETECT_VAR_TYPE_PKT_POSTMATCH` is the only other type, and a post-match callback always has a packet.

Both are allocation-failure paths, bounded by the capture size of 64KB, and neither is influenced by traffic: reaching them requires the allocator to already be failing, and the small `DetectVarList` allocation has to fail while the larger capture allocation that precedes it succeeded. This is a robustness fix rather than a denial-of-service concern.

Suggested fix: free the key and the buffer in both store functions before returning -1, and record in `DetectFlowvarPostMatch` whether the store took ownership so that anything it did not take is freed.

No data to display

Actions

Also available in: PDF Atom