Victor Julien [Fri, 21 Apr 2023 12:12:36 +0000 (14:12 +0200)]
mime: address scan-build warnings
util-decode-mime.c:189:31: warning: Use of memory after it is freed [unix.Malloc]
lastSibling->next = entity->child;
~~~~~~~~~~~~~~~~~ ^
util-decode-mime.c:827:24: warning: Potential leak of memory pointed to by 'val' [unix.Malloc]
state->hname = NULL;
^~~~
/usr/lib/llvm-16/lib/clang/16/include/stddef.h:89:24: note: expanded from macro 'NULL'
# define NULL ((void*)0)
^
2 warnings generated.
Improve error handling and add assert to avoid these warnings.
Victor Julien [Fri, 21 Apr 2023 09:33:43 +0000 (11:33 +0200)]
detect: fix scan-build warnings
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.
Victor Julien [Fri, 21 Apr 2023 09:16:13 +0000 (11:16 +0200)]
mpm/ac-bs: work around scan-build warnings
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.
Victor Julien [Fri, 21 Apr 2023 09:13:19 +0000 (11:13 +0200)]
mpm/ac: work around scan-build warnings
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.
Victor Julien [Fri, 21 Apr 2023 08:25:30 +0000 (10:25 +0200)]
suricata: work around scan-build warnings
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.
Victor Julien [Fri, 21 Apr 2023 08:21:17 +0000 (10:21 +0200)]
stream: fix minor scan-build warning
stream-tcp.c:134:14: warning: Value stored to 'presize' during its initialization is never read [deadcode.DeadStores]
uint64_t presize = SC_ATOMIC_GET(st_memuse);
^~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
Victor Julien [Thu, 20 Apr 2023 17:39:30 +0000 (19:39 +0200)]
debug: suppress warning for scan-build
app-layer-ssl.c:1497:27: error: call to undeclared function 'RecordAlreadyProcessed'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
DEBUG_VALIDATE_BUG_ON(RecordAlreadyProcessed(ssl_state->curr_connp));
^
1 error generated.
Victor Julien [Wed, 12 Apr 2023 17:21:53 +0000 (19:21 +0200)]
pcap: fix return check
The check that meant to check if pcap_dispatch processed fewer packets
than the desired number was inaccurate. It would also include all errors
(negative return values).
This patch considers only positive values for this check.
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.
Justin Azoff [Sat, 18 Feb 2023 02:11:46 +0000 (21:11 -0500)]
detect/iponly: Reduce the size of the SigNumArray bitsets
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.
Victor Julien [Tue, 11 Apr 2023 09:40:35 +0000 (11:40 +0200)]
pcap: improve pcap_breakloop support
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.
Maxim Korotkov [Thu, 16 Feb 2023 17:16:19 +0000 (20:16 +0300)]
output: fix logic error
The logical error may have been made here. Comparison with the upper
bound of the variable type does not make sense. It may be worth adding
the cast of one of the multiplication operands to the 64-bit type for
avoiding overflow.
Found by Security Code with Svace static analyzer
Bug: #5789
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.
Jason Ish [Wed, 15 Mar 2023 22:23:49 +0000 (16:23 -0600)]
app-layer: add direction to transaction creation where needed
Build on Eric's but set the direction on transaction creation when
needed. I think this makes it a little more clear, and easier to
document when creating single direction transactions.
This also somewhat abstracts the inner-workings of a directional
transaction from the implementation.