Ticket: 8629
When we are in async-oneside mode, we see only one direction
of the traffic, and should not wait for the other direction
before cleaning up a transaction.
(cherry picked from commit 7ec9d72d28)
Ticket: 8558
Do not accept an IPv6 as an IPv4 (even if the hash is likely
different in the first place)
Do the check also for ESP, and ebpf
(cherry picked from commit bc41dcc854)
new_tx() now refuses to create a transaction when the list is already at
SMB_MAX_TX, returning None instead of a transaction. Every creation path --
the new_*_tx helpers and their callers across smb1/smb2/dcerpc/session/
files/ioctl -- propagates that, so no single input can create more than the
limit, including a compound SMB2 request that chains many PDUs in one
record. When the list is full the parser puts the flow into an error state
and stops processing it.
This replaces the previous force-completion of old transactions, which did
not reliably bound the list and could leave transactions unreclaimable on
asymmetric flows. The now-unused tx_index_completed bookkeeping is removed.
Issue: 8629
(cherry picked from commit c8f68b0e4f)
Ticket: 8642
Do not allocate too much by using the config value, when the flash
file does not require that much data anyways
(cherry picked from commit d9fae18432)
Ticket: 8600
CreateServiceA doc states for example :
> If the path contains a space, it must be quoted so that it is
correctly interpreted.
Also fixes strlcat usage and check return value to error out on
truncated path
(cherry picked from commit ac1b3cc1ef)
to deal with the failure due to cbindgen updates and mismatches in
generated bindings.
detect-bytemath.c:61: error: "DETECT_BYTEMATH_ENDIAN_DEFAULT" redefined [-Werror]
61 | #define DETECT_BYTEMATH_ENDIAN_DEFAULT (uint8_t) BigEndian
|
In file included from rust.h:34,
from detect-bytemath.c:32:
./../rust/gen/rust-bindings.h:5071: note: this is the location of the previous definition
5071 | #define DETECT_BYTEMATH_ENDIAN_DEFAULT BigEndian
|
error: casting to the same type is unnecessary (`u16` -> `u16`)
--> src/http2/http2.rs:1286:47
|
1286 | if !orig_state.is_null() && orig_proto == ALPROTO_HTTP1 as u16 {
| ^^^^^^^^^^^^^^^^^^^^ help: try: `ALPROTO_HTTP1`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/rust-1.95.0/index.html#unnecessary_cast
note: the lint level is defined here
--> src/lib.rs:23:38
|
23 | #![cfg_attr(feature = "strict", deny(warnings))]
| ^^^^^^^^
= note: `#[deny(clippy::unnecessary_cast)]` implied by `#[deny(warnings)]`
Ticket: 8513
Suricata decides at 2 levels if a http2 flow is doing a compression
bomb.
There is a direct computation when one chunk of TCP data
is being parsed.
In this case, do not take the ratio into account, just use the size
of the decompressed data, so that if we get a big chunk of TCP data
like 1 MiB, and a not so high ratio of 200, we do not trigger
the debug assertion in util-file.c about 64MiB
The other case stays unchanged : when accumulating over the lifetile of
a flow with multiple txs, take into account the compression ratio,
so that a flow of many txs, having a super high (brotli) compression
ratio, ends up classified as a compression bomb.
(For example, having 100 txs each turning a 100 byte input into a 700 KiB
one)
(cherry picked from commit bf64b52b95)
Ticket: 8513
During decompression, fail early if we have a big decompression
ratio, and enough data.
Track this data also during a tx lifetime, and even a flow/state
lifetime, so that we set event and fail also if the compression
bomb is split over multiple packets
(cherry picked from commit 7bf48b02be)
Ticket: 8529
When Suricata handles a HTTP1 response body, it does so with a
file, and tries to get the filename from the Content-Disposition
header if any, then from the uri.
If it failed to find a file name, it tried again every time
there was new data from the response body, even if there was
no new data to find a file name in either the header nor the uri.
This causes a slowdown in the case the Content-Disposition header
is big.
Fix is to set the flag on the first call of the callback, to be
sure that we will parse the Content-Disposition header for a
filename header only once per http1 response.
(cherry picked from commit 9aaa6f7854)
So that we can write a final zero without overflowing the array
and relying on padding to avoid further problems
Ticket: 8448
(cherry picked from commit 38d41e6fa6)
Ticket: 8510
Without this check, in case of a hash collision, and the other
fields are equal, we could end up consider adding an IPv6 packet
to a IPv4 tracker (or vice versa).
Doing so, we end up interpreting an IPv6 packet as an IPv4 one,
and we do not benefit from the bounds checks from ipv4/ipv6 decoder.
(cherry picked from commit 24527d662a)
Ticket: 8526
As some C protocols accepted case-insensitive frame names,
a rule using the same frame twice with different cases,
ended up using 2 different buffers,
which ended up in triggering a buffer overflow
(cherry picked from commit c977b2f31b)
Shivani Bhardwaj
Philippe Antoine
Jeff Lucovsky
Victor Julien
Jason Ish
Eric Leblond
Juliana Fajardini