util-radix-tree.c:595:34: warning: Access to field 'stream' results in a dereference of a null pointer (loaded from field 'prefix') [core.NullDereference]
if ((temp = (stream[i] ^ bottom_node->prefix->stream[i])) == 0) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~
util-radix-tree.c:717:30: warning: Access to field 'stream' results in a dereference of a null pointer (loaded from field 'prefix') [core.NullDereference]
if (SC_RADIX_BITTEST(bottom_node->prefix->stream[differ_bit >> 3],
^~~~~~~~~~~~~~~~~~~~~~~~~~~
./util-radix-tree.h:27:34: note: expanded from macro 'SC_RADIX_BITTEST'
#define SC_RADIX_BITTEST(x, y) ((x) & (y))
^
2 warnings generated.
(cherry picked from commit fa5acc1743)
detect-engine-address.c:1140:17: warning: Use of memory after it is freed [unix.Malloc]
r = DetectAddressCmp(ag, ag2);
^~~~~~~~~~~~~~~~~~~~~~~~~
detect-engine-address.c:1169:17: warning: Use of memory after it is freed [unix.Malloc]
r = DetectAddressCmp(ag, ag2);
^~~~~~~~~~~~~~~~~~~~~~~~~
2 warnings generated.
detect-engine-port.c:1161:9: warning: Use of memory after it is freed [unix.Malloc]
DetectPortPrint(ag2);
^~~~~~~~~~~~~~~~~~~~
1 warning generated.
Bug: #3150.
Bug: #3151.
(cherry picked from commit 000064de7d)
util-mpm-ac-bs.c:482:32: warning: Result of 'malloc' is converted to a pointer of type 'uint16_t[256]', which is incompatible with sizeof operand type 'uint16_t' [unix.MallocSizeof]
ctx->state_table_u16 = SCMalloc(ctx->state_count *
^~~~~~~~
./util-mem.h:35:18: note: expanded from macro 'SCMalloc'
#define SCMalloc malloc
^~~~~~
util-mpm-ac-bs.c:524:32: warning: Result of 'malloc' is converted to a pointer of type 'uint32_t[256]', which is incompatible with sizeof operand type 'uint32_t' [unix.MallocSizeof]
ctx->state_table_u32 = SCMalloc(ctx->state_count *
^~~~~~~~
./util-mem.h:35:18: note: expanded from macro 'SCMalloc'
#define SCMalloc malloc
^~~~~~
2 warnings generated.
Bug: #3148.
(cherry picked from commit c8694634af)
util-mpm-ac.c:531:32: warning: Result of 'malloc' is converted to a pointer of type 'uint16_t[256]', which is incompatible with sizeof operand type 'uint16_t' [unix.MallocSizeof]
ctx->state_table_u16 = SCMalloc(ctx->state_count *
^~~~~~~~
./util-mem.h:35:18: note: expanded from macro 'SCMalloc'
#define SCMalloc malloc
^~~~~~
util-mpm-ac.c:575:32: warning: Result of 'malloc' is converted to a pointer of type 'uint32_t[256]', which is incompatible with sizeof operand type 'uint32_t' [unix.MallocSizeof]
ctx->state_table_u32 = SCMalloc(ctx->state_count *
^~~~~~~~
./util-mem.h:35:18: note: expanded from macro 'SCMalloc'
#define SCMalloc malloc
^~~~~~
2 warnings generated.
Bug: #3148.
(cherry picked from commit ee683a7074)
util-mpm-hs.c:340:20: warning: Potential leak of memory pointed to by 'p' [unix.Malloc]
p->sids[0] = sid;
~~~~~~~~~~~^~~~~
1 warning generated.
Incorrect error handling could lead to a memory leak.
(cherry picked from commit ec84ba1a3c)
suricata.c:691:17: warning: Value stored to 'bits' during its initialization is never read [deadcode.DeadStores]
const char *bits = "<unknown>-bits";
^~~~ ~~~~~~~~~~~~~~~~
suricata.c:692:17: warning: Value stored to 'endian' during its initialization is never read [deadcode.DeadStores]
const char *endian = "<unknown>-endian";
^~~~~~ ~~~~~~~~~~~~~~~~~~
2 warnings generated.
(cherry picked from commit c13a6fa73c)
Update the GitHub CI workflow to use the bundle.sh script to pull in
Suricata-Update and libhtp. This means one less place where defaults
are hardcoded and can get out of sync.
This also simplifies the variable names that can be embedded in a pull
request message to use the same variable names that bundle.sh
expects. Of note, this removes the _PR variant, instead a branch name
of "pr/N" can be used to specify a PR.
Allow pull requests (and merge requests) to be specified by using a
branch name like "pr/111" or "mr/222". This allows CI to use this
script as well, instead of multiple variations of the same thing.
Additonally allow the destination directory to be overridden with the
DESTDIR environment variable.
Instead of tracking ip only rules by the internal signum, track them by
a separate counter that starts at zero. This results in dense
SigNumArrays instead of sparse ones and a much smaller max_idx.
Issue: 4578
(cherry picked from commit dfbc3da0eb)
Before:
If LF character was found, so far, we won't enforce the line limit on
the line. We only enforced limits in case of LF character missing in a
long line.
After this patch:
Line limit is enforced on the line if it is bigger than 4096 Bytes
irrespective of whether LF was found or not.
Redmine Bug: 5819
(cherry picked from commit 5f52b199ff)
When pcap_breakloop has been issued on a handle, the current pcap_dispatch
call may return -2 (PCAP_ERROR_BREAK), but it can also return the number
of processed packets if lower than the desired number. So add this condition
as a check.
(cherry picked from commit 9fe08f2374)
(cherry picked from commit 2ddd26446e)
During housekeeping multiple flows are processed. If a rule reload happens
at that time, we need to use the new detect thread as soon as possible.
Bug: #5969.
(cherry picked from commit 5e4cf182ab)
avoid quadratic complexity from removing the first element
and copying all the contents a big number fo times.
Ticket: #5909
(cherry picked from commit 9adb59bcdb)
In the case we are truncating a multipart file because of reaching
request.body-limit, we used to not consume the whole buffer, but
keep expected_boundary_len bytes in case a new boundary begins
in these bytes.
Even if we cannot check the complete boundary, we can still check
the first bytes, as will be done in the rust version.
Ticket: #5952
(cherry picked from commit 578f328e06)
(cherry picked from commit caf9940fd1)
After recent next_seq changes, the FIN checks could be too strict
leading to stalling sessions in IPS mode.
This patch requires a FIN to be >= last ack and <= next_win to be
accepted.
(cherry picked from commit 39a6f411e9)
Old behavior:
With RFC4648, the decoded bytes were reset to 0 in case an unusual
character was encountered in the encoded string. This worked out fine
for small test cases where there weren't many bytes to be decoded.
Problem:
If a big encoded string had a character outside of the base alphabet,
the processing would stop and the number of decoded bytes were set to 0.
However, even though the processing should stop at the invalid
character, the number of decoded bytes should correctly store the bytes
decoded up until the point an invalid characted was encountered.
New behavor:
For any base64 encoded string given to the base64 decoder in RFC4648
mode, we make sure that the number of decoded bytes correctly reflect
the number of bytes processed up until the string was valid. This makes
sure any further calculations/use of the decoded data is done correctly.
Redmine ticket: 5885
(cherry picked from commit 418ddba38e)
Stamus team did discover a problem were a signature can shadow
other signatures.
For example, on a PCAP only containing Kerberos protocol and where the
following signature is matching:
alert krb5 $HOME_NET any -> any any (msg:"krb match"; krb5_cname; content:"marlo"; sid:3; rev:1;)
If we add the following signature to the list of signature
alert ssh $HOME_NET any -> any any (msg:"rr"; content:"rr"; flow:established,to_server; sid:4; rev:2;)
Then the Kerberos signature is not matching anymore.
To understand this case, we need some information:
- The krb5_cname is a to_client keyword
- The signal on ssh is to_server
- Kerberos has unidirectional transaction
- kerberos application state progress is a function always returning 1
As the two signatures are in opposite side, they end up in separate
sig group head.
Another fact is that, in the PCAP, the to_server side of the session
is sent first to the detection. It thus hit the sig group head of
the SSH signature. When Suricata runs detection in this direction
the Kerberos application layer send the transaction as it is existing
and because the alstate progress function just return 1 if the transaction
exists. So Suricata runs DetectRunTx() and stops when it sees that
sgh->tx_engines is NULL.
But the transaction is consumed by the engine as it has been evaluated
in one direction and the kerberos transaction are unidirectional so
there is no need to continue looking at it.
This results in no matching of the kerberos signature as the match
should occur in the evaluation of the other side but the transaction
with the data is already seen has been handled.
This problem was discovered on this Kerberos signature but all
the application layer with unidirectional transaction are impacted.
This patch introduces a flag that can be used by application layer
to signal that the TX should not be inspected. By using this flag
on the directional detect_flags_[ts|tc] the application layer can
prevent the TX to be consumed in the wrong direction.
Application layers with unidirectional TX will be updated
in separate commits to set the flag on the direction opposite
to the one they are.
Ticket: #5799
Victor Julien
Jason Ish
Justin Azoff
Jeff Lucovsky
Shivani Bhardwaj
Philippe Antoine
Eric Leblond