282423f...
by
Shivani Bhardwaj <email address hidden>
version: start development towards 6.0.20
d5f5ca0...
by
Shivani Bhardwaj <email address hidden>
release: 6.0.19; update changelog
cb823d4...
by
Victor Julien <email address hidden>
http2: fix for rustc 1.41.1
Co-authored-by: Philippe Antoine <email address hidden>
d24b37a...
by
Philippe Antoine <email address hidden>
http2: do not log duplicate headers
Ticket: 6900
And thus avoid DOS by logging a request using a compressed
header block repeated many times and having a long value...
(cherry picked from commit 03442c9071b8d863d26b609d54c6eacf4de9e340)
08d93f7...
by
Philippe Antoine <email address hidden>
http2: use a reference counter for headers
Ticket: 6892
As HTTP hpack header compression allows one single byte to
express a previously seen arbitrary-size header block (name+value)
we should avoid to copy the vectors data, but just point
to the same data, while reamining memory safe, even in the case
of later headers eviction from the dybnamic table.
Rust std solution is Rc, and the use of clone, so long as the
data is accessed by only one thread.
(cherry picked from commit 390f09692eb99809c679d3f350c7cc185d163e1a)
1099eec...
by
Philippe Antoine <email address hidden>
detect/parse: set limits for pcre2
Ticket: 6889
To avoid regexp dos with too much backtracking.
This is already done on pcre keyword, and pcrexform transform.
We use the same default limits for rules parsing.
(cherry picked from commit 316cc528f784c86339d05907a4d6084cbe4d44e6)
Using pcre1 in master6
d5ffecf...
by
Philippe Antoine <email address hidden>
util/base64: fix buffer overflow
Ticket: 6902
In case the caller of DecodeBase64 does not supply a big enough
output buffer.
(cherry picked from commit fd47e67dc65f9111895c88fb406c938b1f857325)
The list of fragments may still contain overlaps, so adding up the
fragment lengths is flawed. Instead track the largest size of
contiguous data that can be re-assembled.
Bug: #6675
(cherry picked from commit d226d0a3fce8837936e1bdfaee496c80d417e0a5)
defrag: fix subsequent overlap of start of original (bsd)
Fix the BSD policy case where a subsequent fragment starts before an
original fragment and overlaps the beginning of the original
fragment. In this case the overlapping data from the new fragment is
preferred.
Suricata was preferring the data from the original fragment, but it
should only do that when the original fragment has an offset <= to the
new fragment.
- Adds tests for this case
Bug: #6669
(cherry picked from commit f1709ea551124e1a64fdc509993ad022ab27aa77)
defrag: check next fragment for overlap before stopping re-assembly
Instead of breaking the loop when the current fragment does not have
any more fragments, set a flag and continue to the next fragment as
the next fragment may have data that occurs before this fragment, but
overlaps it.
Then break if the next fragment does not overlap the previous.
Bug: #6668
(cherry picked from commit d0fd0782505d837e691ceef1b801776f0db82726)
