Since userguide/conf.py uses the deprecated get_html_theme_path(),
sphinx emits a warning which breaks the build as warnings are treated
as errors.
Issue: 7859
In util-hash.c there was some behavior that is unexpected and likely
incorrect. To see this behavior, create a hash table 32 entries wide
and use the default hash function. Then add a short string “abc”,
observe the string is stored properly. Now remove a string “iln”, and
observe string “abc” is no longer in the table.
This is because the hash function is not properly handling collisions in
some edge cases.
Includes new unit test:
- UT verifies that the hash function generates a collision for
the selected test data. This must be true for the bug to be present.
Then UT demonstrates the bug by adding two items to the hash table
that collide, and then removing one of them 2x. The bug is that the
other value is removed as well.
Bug #7828 --> https://redmine.openinfosecfoundation.org/issues/7828
Signed-off-by: Charlie Vigue <charlie.vigue@openvpn.com>
de_ctx->rule_file is never NULL inside DetectFileHashParse(); add a comment
stating this fact and remove the superfluous NULL guard.
No functional change – the patch only clarifies the code and trims a few
lines of dead code.
Bug 7769
Issue: 7853
Support the use of `from_base64` with no optional values. In this case,
the default values for:
- mode RFC4648
- offset: 0
- bytes: buffer size
will be used.
This commit modifies the call path for registering MT tenants to avoid
deadlocks on the master->lock
When performing tenant operations, e.g., using suricatasc to send a
register-tenant command, a deadlock occurs when
- DetectEngineMTApply: acquires master->lock
- Calls DetectEngineReloadThreads
- Within DetectEngineReloadThreads, calls DetectEngineMultiTenantEnabled
- Which first acquires master->lock
Commit 2bea5af introduced changes to the master->lock usage leading to
the deadlock situation.
Issue: 7819
Fix new warning present in Rust 1.89.
warning: hiding a lifetime that's elided elsewhere is confusing
--> src/ldap/types.rs:191:30
= help: the same lifetime is referred to in inconsistent ways, making the signature confusing
= note: `#[warn(mismatched_lifetime_syntaxes)]` on by default
help: use `'_` for type paths
The failure report was always just written to rules_fast_pattern.txt. In
case that setting is disabled or there's nothing fast-pattern related,
the report should be written to the usual rules_analysis.txt.
Bug 7821
de_ctx->ea->fp_engine_analysis_fp is only initialized if
engine-analysis.rules-fast-pattern is enabled in the configuration. If
this config param is missing, this leads to segfault.
Bug 7822
Remove unused rule prefilter-related stats counters that aren't in use.
94644ac960 (detect: move non-pf rules into special prefilter engines)
removed the logic that made use of and incremented the stats counters:
- det_ctx->counter_fnonmpm_list
- det_ctx->counter_nonmpm_list
Some code was left, registering them, and mentioning them in the
json schema.
Ticket #7834
Fixed counter for ippair.memcap by using the correct function,
IPPairGetMemcap.
Until now IPPairGetMemuse was used both for memuse and memcap.
Ticket: 7827
- cleanup usage and documentation around needs
- mentiond that rule hooks are used instead of "needs" keywords with
link with rule hooks (which is still in the firewall-design doc)
Based on the current AlmaLinux 9 build, with plugin tests, etc.
Remove cppclean as its not installed and was previously disabled with
commit 2d308c000d.
Since cached_hash was updated through reference (hash), it seems
LTO did not notice this and optimized the whole code block, returning
zero.
This in turn caused all caches to have the same name and to overwrite.
On subsequent runs, only the last cache was loaded for all SGHs
causing wrong MPM assignment.
Ticket: 7824
Ubuntu and Fedora packing system build with -flto=auto by default, so
update one test to use -flto=auto. Also build with -O2 as that
combination can cause issues such as
https://redmine.openinfosecfoundation.org/issues/7824.
Also adds vectorscan to the build.
Functions like ByteExtractStringUint8 return 0 or less on
failure. Many usages of this function treat 0 as successful as its our
common pattern.
Ticket: #7836