When a "stream starter" packet finds an existing TCP flow, the flow will be
evaluated for reuse.
The following scenario wasn't handled well:
1. Suricata starts after a tool has just stopped using lots of connections
(e.g. ab stress testing a webserver)
2. even though the client is closed already, the server is still doing
connection cleanup sending many FINs and later RSTs
3. Suricata creates flows for these packets, but no TCP sessions
4. client resumes testing, creating flows that have the same 5 tuple as the
flows created for the FIN/RST packets
5. Suricata refuses to "reuse" the flows as the condition "tcp flow w/o session"
is not considered valid for session reuse
6. new TCP connection is not properly tracked and evaluated in parsing and
detection
There may be other vectors into this, like a flow w/o session because of
memcap issues.
Bug: #5843.
Incorrect "end" region for consolidation was selected if the "dst"
would be expanded to overlap with it.
Fix list handling when the first region to consider (src_start) was
not the list start.
Bug: #5833.
Bug: #5834.
Enforce assumption that packets in ThreadVars::decode_pq have no flow
attached to it because this is only true for packets while they are
in the FlowWorker.
Packets only ever reference the flow while holding its lock. This
means than any code possibly evicting the flow will have to wait
for the existing users to complete their work. Therefore the use_cnt
serves no function anymore and can be removed.
An array of interfaces was being logged without creating an array,
resulting in duplicate "interface" objects being logged. Instead put
these interfaces into an array like already done elsewhere.
Issue: 5814
Looks like this was due to an error in the dcerpc logging where the
interfaces should have been logged to the "interfaces" array that was
already defined.
Issue: 5814
Remove the second occurrence of tree_id logging which appears to
always be a duplicate of the first tree_id logged, even though they
come from different data structures.
Issue: 5811
The Rust time crate used by the x509-parser crate represents dates
before 1970 as negative numbers which do not survive the conversion to
SCTime_t and formatting with the current time formatting functions.
Instead of fixing our formatting functions to handle such dates,
create a Rust function for logging TLS dates directly to JSON using
the time crate that handles such dates properly.
Also add a FFI function for formatting to a provided C buffer for the
legacy tls-log.
Issue: 5817
Inspect individual chunks in lossy traffic.
Don't use the frame idx as the inspection buffer idx. Engines are running
per frame, so multi inspection can be used for stream chunks instead.
Ticket: #4977.