Issue: 6527
Address the FP raised by cppcheck -- note that although the code
corectly checks to ensure that `to_shift != &sb->reqion`, the logic was
detected as a FP. Rework the code to eliminate the FP.
DETECT_FLOWBITS_CMD_NOALERT is misleading as it gives an impression that
noalert is a flowbit specific command that'll be used and dealt with at
some point but as soon as noalert is found in the rule lang, signature
flag for noalert is set and control is returned. It never gets added to
cmd of the flowbits object.
There is nothing Address specific going on in the preparations.
Stage 1: Preprocessing happens. Sigs classified as IP Only, Masks
applied, content specific limits applied, etc and sig array built.
Stage 2: Sigs grouped by IPOnly, ports and protocols.
Stage 3: Decoder Events SGH built.
Stage 4: File flags set, sig grouping done per prefilter, etc.
Parallel builds caused issues during `cargo vendor`. So do just a single
thread build.
make[4]: Entering directory '/__w/suricata/suricata/rust'
cbindgen --config /__w/suricata/suricata/rust/cbindgen.toml \
--quiet --output /__w/suricata/suricata/rust/dist/rust-bindings.h
CARGO_HOME="/github/home/.cargo" /usr/bin/cargo vendor
Blocking waiting for file lock on package cache
Blocking waiting for file lock on package cache
ERROR: Couldn't execute `cargo metadata` with manifest "/__w/suricata/suricata/rust/Cargo.toml": Metadata(Output { status: ExitStatus(unix_wait_status(25856)), stdout: "", stderr: " Blocking waiting for file lock on package cache\n Blocking waiting for file lock on package cache\nerror: failed to download `adler v1.0.2`\n\nCaused by:\n unable to get packages from source\n\nCaused by:\n failed to parse manifest at `/github/home/.cargo/registry/src/github.com-1ecc6299db9ec823/adler-1.0.2/Cargo.toml`\n\nCaused by:\n no targets specified in the manifest\n either src/lib.rs, src/main.rs, a [lib] section, or [[bin]] section must be present\n" })
ERROR: Couldn't generate bindings for /__w/suricata/suricata/rust.
make[4]: *** [Makefile:597: dist/rust-bindings.h] Error 1
make[4]: *** Waiting for unfinished jobs....
Since recursive content matching goes through the buffer from left to
right, it is possible to bail early when isdataat is part of the
recursive checking. If `isdataat:50,relative` fails for offset 10, it
will surely also fail for offset 20. So break inspection in such cases.
The exception is for dynamic isdataat, where the value is determined
by a prior byte_extract that may be updated during the recursion.
Use stack local var instead of DetectEngineThreadCtx member. Instead
setup a stack local struct that both counts and holds the limit. Make sure
the limit is a const so we can avoid rereading it.
This is part of an effort to reduce the size of the DetectEngineThreadCtx
structure and reduce the number of memory writes to it. Additionally, it
is part of an effect to reduce the number of places where detection
tracks various forms of state.
Fix SCTIME_ADD_SECS zeroing subsecond part
When adding s seconds to SCtime_t ts, don't zero out the ts.usecs field.
Issue: 6584
Fix SCTIME_FROM_TIMESPEC garbage microseconds part
When converting nanosecond to microseconds divide by 1000 instead
of multiplying by 1000.
Issue: 6585
Initialize both seconds and useconds of packet timestamp from napatech
timestamp format.
This commit uses updated macro definitions from util-utime.h to avoid
zero seconds value.
Issue: 6372
legacy map definition is removed from libbpf1.0+.
update the legacy map definition to BTF defined map.
Distros with < libbpf1.0 (0.5, 0.6, 0.7, 0.8) bpf_helpers.h
support BTF map definition, this change does not break
old libbpf and support new libpbf1.0+.
Bug: #6250
Signed-off-by: Vincent Li <vincent.mc.li@gmail.com>
Co-authored-by: Victor Julien <vjulien@oisf.net>
With the changes in the probing_ts function, this other one could become
obsolete. Remove it, and directly call `parser::parse_request` when
checking for gaps, instead.
Some non-pgsql traffic seen by Suricata is mistankenly identified as
pgsql, as the probing function is too generic. Now, if the parser sees
an unknown message type, even if it looks like pgsql, it will fail.
Bug #6080
We had unkonwn message type for the backend, but not the frontend
messages. It's important to better identify those to improve pgsql
probing functions.
Related to
Bug #6080
Jason Ish
Jeff Lucovsky
Philippe Antoine
Shivani Bhardwaj
Victor Julien
Stephen Donnelly
Ilya Bakhtin
Juliana Fajardini
jason taylor
Vincent Li