We were including "autoconf.h" in our dist releases, however this file
is generated by ./configure. This can be problematic in out of tree
builds as the one included in the dist, not the generated one may be
used.
Also using "autoconf.h" instead of <autoconf.h> so it is searched for
relative to the file including it which is necessary if a library/plugin
does something like "#include "suricata/foo.h".
Provide an example of an extremely simple application that links
against Suricata. This provides a Makefile integrated with the
Suricata build system for in-tree building, as well as an example
Makefile for building out of tree.
Currently this application just wraps SuricataMain and does nothing
else.
Simplify the Makefile by avoiding automake and providing our own
Makefile.in that is suitable for in-tree builds of the plugin and can
also serve as an example for standalone plugins.
But the bigger benefit of this is to allow building the example plugin
even with --disable-shared provided to configure, as this is just a
phony limitation imposed by automake/libtool.
Issue: 5172
This commit forces the current stream to be closed when a hard error
occurs.
Without this commit, a hard error will force a 2nd connection
the stream that raised the error.
With this commit, the stream with the hard error is closed before
opening another connection to the stream.
Verified with the Python snippet in the redmine issue.
If CONCURRENCY_LEVEL was set, the script would log a concurrency level
even if the parallel command was not available. Not log if parallel is
not available and set concurrency to 1.
When an interface with dots is used, per worker stats are nested by the
dot-separated-components of the interface due to the usage of
OutputStats2Json().
Prevent this by using OutputStats2Json() on a per-thread specific object
and setting this object into the threads object using the
json_object_set_new() which won't do the dot expansion.
This was tested by creating an interface with dots in the name
and checking the stats.
ip link add name a.b.c type dummy
With Suricata 7.0.2, sniffing on the a.b.c interface results in the
following worker stats format:
"threads": {
"W#01-a": {
"b": {
"c": {
"capture": {
"kernel_packets": 0,
After this fix, the output looks as follows:
"threads": {
"W#01-a.b.c": {
"capture": {
"kernel_packets": 0,
Ticket: #6732
The runtime complexity of insertion sort is approx. O(h*n)^2 where
h is the size of the HOME_NET and n is the number of ip only rules
that use the HOME_NET.
Replacing this with qsort significantly improves rule load time when
a large HOME_NET is used in combination with a moderate amount of ip
only rules.
Ticket: 6617
So that rules with keyword like `filestore:to_server,flow`
only store the files to server and not the ones to client...
Directionality only worked with the default scope, ie the
current file, and not the scope tx or scope flow.
For non-default scope, tx or flow, both directions were stored
whatever the directionality specified.
For these non-default scopes, this commit keeps a default
of both directions, but use only one direction if specified.
Need to split flag FLOWFILE_STORE per direction, so that Suricata
can retain this (optional) directional info from the filestore
keyword.
Fixes: 79499e4769 ("app-layer: move files into transactions")
Rework locking logic to avoid the following coverity warning.
** CID 1591966: Concurrent data access violations (MISSING_LOCK)
/src/detect-engine-loader.c: 475 in DetectLoadersSync()
474 SCCtrlMutexLock(loader->tv->ctrl_mutex);
>>> CID 1591966: Concurrent data access violations (MISSING_LOCK)
>>> Accessing "loader->tv" without holding lock "DetectLoaderControl_.m". Elsewhere, "DetectLoaderControl_.tv" is written to with "DetectLoaderControl_.m" held 1 out of 1 times (1 of these accesses strongly imply that it is necessary).
475 pthread_cond_broadcast(loader->tv->ctrl_cond);
476 SCCtrlMutexUnlock(loader->tv->ctrl_mutex);
The warning itself is harmless.
Dependabot is always getting flagged as a new author even tho it uses
a consistent author of:
dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
But this doesn't work with plain grep. Fix by telling grep to treat
the value as a fixed string instead of a regular expression.
As we don't have a Cargo.toml and a Cargo.lock, dependabot for Rust
hasn't been working correctly. Disable, as we now have our own cargo
audit and update workflows.
Ensure that the mutex protecting the condition variable is held before
signaling it. This ensures that the thread(s) awaiting the signal are
notified.
Issue: 6569
Multiple uploads can no longer use the same name, so give the cbindgen
artifact its own name of "cbindgen". Requires an additional download
for each build depending on this cbindgen artifact.
CentOS 7 requires older actions due to newer GitHub actions depending
on a newer glibc. So move to its own workflow file so the main builds
can move forward to newer versions of actions.
Add GitHub actions to perform:
- cargo audit: catch new warnings in dependendent packages
- cargo update: catch updated dependencies that depend on a new MSRV
than we use
A dead lock could occur at start up, where a loader thread would
get stuck on it's condition variable, while the main thread was
polling the loaders task results.
The vector to the dead lock is as follows:
main loader
DetectEngineMultiTenantSetup
-DetectLoaderSetupLoadTenant
--DetectLoaderQueueTask
---lock loader
---add task
---unlock loader
lock loader
check/exec tasks
unlock loader
---wake up threads
lock ctrl mutx
cond wait ctrl
unlock ctrl
-DetectLoadersSync
--lock loader
--check tasks
--unlock loader
Between the main thread unlocking the loader and waking up the
threads, it is possible that the loader has already moved ahead
but not yet entered its conditional wait. The main thread sends
its condition signal, but since the loader isn't yet waiting on
it the signal is ignored. Then when the loader does enter its
conditional wait, the signal is not sent again.
This patch updates the logic to send signals much more often.
It also makes sure that the signal is sent under lock, as the
API requires.
Bug: #6766.
Issue: 6755
When NetmapOpen encounters an error opening the netmap device, it'll
retry a bit. When the retry limit is reached, it'll shutdown Suricata.
This commit ensures that the device list lock is not held when before
closing all open devices before terminating Suricata.
Jason Ish
Jeff Lucovsky
Shivani Bhardwaj
Arne Welzel
Simon Dugas
Philippe Antoine
Victor Julien
Jeff Lucovsky
dependabot[bot]
Lukas Sismis
Lukas Sismis
jason taylor
Daniel Olatunji
Alexey Simakov