Replace duplicated SCFree() calls in error paths with a single
cleanup label using goto pattern. This reduces code duplication
and ensures consistent resource cleanup.
Additional improvements:
- Fix misleading error message when xstats table size changes
between calls (was passing positive value to rte_strerror)
- Use unsigned int for length/index to match DPDK API semantics
- Initialize xstats_names to NULL at declaration for safe cleanup
- Added "not supported" case when the first call to xstats_get returns 0
Ticket: 8273
... to account for midstream sessions.
Commit 497394e removed inspection of app-proto txs for packets
without an established TCP connection. But this meant that the
first packet seen in a session pick mid-stream could go without
inspection (previous bug 5510 seemed to point towards this behavior,
too).
If a flow has more packets, the stream will be inspected as part of
the upcoming packets and this would go unnoticed. In a single-packet
flow, however, the inspection for the packed would be skipped. Although
this might not affect alerts -- as they could be processed as part of
the flow timeout logic, the actual traffic could be evaded in IPS, in
case of a drop rule.
From the above, the most visible scenario is when there is only one packet on the flow,
as then the engine doesn't have "more time" to pick-up real-packets to
inspect for that given flow. But certain tests show that this can also
happen for more than one packet scenarios: there will be one less drop
event, or traffic from a packet that should have been already dropped
will be logged.
This led to the possibility of a real packet not being blocked, in IPS,
or matched against rules, as the corresponding portion of the stream
was only inspected later, as part of the stream/flow-timeout logic.
To ensure that we correctly flag the first packet seen for a given mid-stream
session, we must check for the session state and existance *after* we
have dealt with TCP flags and state.
Related to
Bug #5510
As part of
Bug #5180
During initialization, the engine reports how many rules were loaded, as
well as which types. Pkt-only or stream-pkt rules would cause a "hole"
in such stats, as they're not counted.
Previously we were boxing a u8 and returning it as a pointer to a
boolean. While this is probably not an issue itself, the value 2 was
allowed to be converted to a boolean, which is undefined behavior in
Rust.
cargo audit reports this security issue with the time crate but Suricata
remains unaffected as no influenced fn is used by Suricata.
Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0009
The MSRV for newer time crate versions are higher than the MSRV for
Suricata right now: 1.75.0
Hence, the best course of action is to suppress this warning.
Ticket: 8269
and bindgen it to rust
Will make easier the bindgen of RustParser structure which uses
a callback which uses AppLayerTxData
Move also the free function to C SCAppLayerTxDataCleanup
As suricata-sys crate defines AppLayerTxData for rust,
It must itself implement the Drop trait, and thus,
We need to define a feature surest
and bindgen it to rust
Will make easier the bindgen of RustParser structure which uses
a callback which uses AppLayerResult
Keep From<> impl in sys crate that defines it
and bindgen it to rust, and use default trait instead of new
Will make easier the bindgen of RustParser structure which uses
a callback which uses AppLayerStateData
Redmine ticket: #8261
According to [1], the within pointer (if combined with distance)
includes the distance pointer, which is not clearly visible in the
graphic.
Fixed this in a new graphic by some GIMP arts.
PS: Special thanks to one of our team members Annika C. for initially
spotting this!
[1] https://forum.suricata.io/t/is-within-affected-by-distance/1688
Unittests test_parse_bind_pdu_infinite_loop and
test_parse_bindack_pdu_infinite_loop seem to have artificially made up
header which does not hold up to the strict calculations enforced by the
parser now. Their headers mark the fraglens as 64 and 72 respectively
which are not enough to hold the kind of bind(ack) items that are expected.
It worked so far as the parser passed the entire input slice around but
with the bugfix for issue 7546, the input passed around is strictly
restricted to the fraglen parsed in the header.
Bug 7546
So far, the fraglen defined in the header was used inconsistently in
certain places to define bounds on input length. Make it consistent by
making sure that only a slice up until fraglen is passed around as that
is the maximum length the fragment should have.
With the help of Applayer::incomplete API, the case when the
stream_slice passed to the parser is smaller than the header defined
fraglen is already handled.
Bug 7546
The parser could receive an input that consists of arbitrary data post
gap. This is handled in the beginning of the fn handle_input_data.
However, the rest of the calculation does not take into account the
bytes that were consumed at this stage. Fix the indices and calculations
to consider a new DCERPC fragment beginning post these consumed bytes.
Issue: 6693
Clarify how the bitmask value is used for byte_jump
Snort compatibility says:
- The bitmask value is applied to the extracted value before the
multiplier is applied.
- The result of the bitmask operation is to be right shifted by the
number of trailing 0's in the bitmask value.
Makes leak sanitizer work without adding LSAN_OPTIONS=use_unaligned=1
Otherwise, leak sanitizer may report the read and black tree pointers
as leaked when it is still owned by some global variable.
Follow-up on d046e82db6
Philippe Antoine
Victor Julien
Lukas Sismis
Juliana Fajardini
Jason Ish
Shivani Bhardwaj
Andreas Dolp
Mingyu Jeon
Jeff Lucovsky