When viewing the docs online at Readthedocs, or similar it might be
immediately apparent what version of the documentation is being
displayed. Display the version on the first line before the table of
contents to make it clear.
Data on RST packets is not invalid, but also shouldn't be used
in reassembly.
RFC 1122:
4.2.2.12 RST Segment: RFC-793 Section 3.4
A TCP SHOULD allow a received RST segment to include data.
DISCUSSION
It has been suggested that a RST segment could contain
ASCII text that encoded and explained the cause of the
RST. No standard has yet been established for such
data.
RST data will be presented to the detection engine per packet,
but will not be part of stream reassembly.
Bug: #6244.
Issue: 6094
Not all stat names are scoped, e.g. decoder.pkts is scoped to decoder;
mempressure_max is unscoped.
The concept of a short-name is added to the underlying stat structure so
- Calculation is done once, at stat registration time
- The output code can easily determine if a stat has a scope
So far, if only the starting request was a DCERPC request, it would be
considered DCERPC traffic. Since ALTER_CONTEXT is a valid request type,
it should be accepted too.
Reported and patch proposed in the following Redmine ticket by
InterNALXz.
Bug 6191
With the release of 7, people are starting to have issues with traffic
being blocked. While we don't add a more expansive documentation for
this, add a link to the FAQ covering possible fixes for drops caused by
the fail closed default behavior of the exception policies.
Since many implementations use the ReleasePacket callback to issue
their verdict, no thread ctx is available. To work around this
just register the stats in a `thread_local` variable instead.
To address:
In file included from /usr/include/string.h:535,
from suricata-common.h:108,
from util-decode-mime.c:26:
In function ‘memcpy’,
inlined from ‘ProcessBase64Remainder’ at util-decode-mime.c:1201:13:
/usr/include/mipsel-linux-gnu/bits/string_fortified.h:29:10: warning: ‘__builtin_memcpy’ forming offset 4 is out of the bounds [0, 4] of object ‘block’ with type ‘uint8_t[4]’ {aka ‘unsigned char[4]’} [-Warray-bounds=]
29 | return __builtin___memcpy_chk (__dest, __src, __len,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
30 | __glibc_objsize0 (__dest));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~
util-decode-mime.c: In function ‘ProcessBase64Remainder’:
util-decode-mime.c:1174:13: note: ‘block’ declared here
1174 | uint8_t block[B64_BLOCK];
| ^~~~~
Copy data should be <= 4 bytes.
detect-engine.c: In function ‘DetectKeywordCtxHashFunc’:
detect-engine.c:3550:75: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
3550 | uint64_t hash = StringHashDjb2((const uint8_t *)name, strlen(name)) + (uint64_t)ctx->data;
|
Seen in Debian QA on mipsel.
util-sysfs.c: In function ‘SysFsWriteValue’:
util-sysfs.c:50:45: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 4 has type ‘int64_t’ {aka ‘long long int’} [-Wformat=]
50 | snprintf(sentence, sizeof(sentence), "%ld", value);
| ~~^ ~~~~~
| | |
| | int64_t {aka long long int}
| long int
| %lld
Move pcre2 data structures used for parsing into the detect engine
context, so that multiple tenant loading threads don't use the same
data structures.
Bug: #4797.
Juliana Fajardini
Jason Ish
Victor Julien
jason taylor
Andreas Herz
Jeff Lucovsky
Shivani Bhardwaj
Lukas Sismis
Philippe Antoine
Cole Dishington