- Replaced strtoul/strtoull with ByteExtractString* for safer and more consistent parsing.
- Allowed max-dump to be set to 0, and correctly apply a core dump limit of 0, maintaining behavior consistent with the commented default in suricata.yaml.in.
- Added and registered unit tests to validate the updated logic.
Ticket: #7212
When no CPU set is explicitly defined, switch from
UtilCpuGetNumProcessorsConfigured() (which counts all existing CPU
cores, even offline ones) to UtilCpuGetNumProcessorsOnline() (only
the available cores).
If Suricata initializes more threads than online CPUs it oversubscribes
the system. As Suricata does not support any runtime live reconfiguration
Suricata initializes only as many cores as online CPU cores.
Ticket: 7790
CID 1593187: (#1 of 1): Data race condition (MISSING_LOCK)
2. missing_lock: Accessing (*p).nfq_v.mark without holding lock Packet_.persistent.tunnel_lock. Elsewhere, NFQPacketVars_.mark is written to with Packet_.persistent.tunnel_lock held 2 out of 5 times (2 of these accesses strongly imply that it is necessary).
No concurrency happening on non-tunnel packet, so no locking needed.
lock_acquire: Calling pthread_mutex_lock acquires lock PktPoolLockedStack_.mutex.
87 SCMutexLock(&my_pool->return_stack.mutex);
CID 1554228: (#1 of 1): Indefinite wait (BAD_CHECK_OF_WAIT_COND)
dead_wait: A wait is performed without ensuring that the condition is not already satisfied while holding lock PktPoolLockedStack_.mutex. This can cause a deadlock if the notification happens before the lock is acquired.
Acquire the lock, then check the wait condition in a loop, without releasing with the lock before the wait. This will prevent deadlocks and failed conditions from spurious wakeups.
lock_acquire: Calling pthread_mutex_lock acquires lock ThreadVars_.ctrl_mutex.
725 SCCtrlMutexLock(th_v->ctrl_mutex);
CID 1554214: (#1 of 1): Indefinite wait (BAD_CHECK_OF_WAIT_COND)
dead_wait: A wait is performed without ensuring that the condition is not already satisfied while holding lock ThreadVars_.ctrl_mutex. This can cause a deadlock if the notification happens before the lock is acquired.
Acquire the lock, then check the wait condition in a loop, without releasing with the lock before the wait. This will prevent deadlocks and failed conditions from spurious wakeups.
In flow manager and recycler timed condition wait loops.
First check loop break conditions before entiring the timed wait.
CID 1638284: (#1 of 1): Indefinite wait (BAD_CHECK_OF_WAIT_COND)
dead_wait: A wait is performed without ensuring that the condition is not already satisfied while holding lock flow_manager_ctrl_mutex. This can cause a deadlock if the notification happens before the lock is acquired.
CID 1638293: (#1 of 1): Indefinite wait (BAD_CHECK_OF_WAIT_COND)
dead_wait: A wait is performed without ensuring that the condition is not already satisfied while holding lock flow_recycler_ctrl_mutex. This can cause a deadlock if the notification happens before the lock is acquired.
CID 1554235: (#1 of 1): Data race condition (MISSING_LOCK)
missing_lock: Accessing defragtracker_spare_q.len without holding lock DefragTrackerStack_.m. Elsewhere, DefragTrackerStack_.len is written to with DefragTrackerStack_.m held 2 out of 2 times.
To assist coverity, which got confused:
CID 1649393: (#1 of 1): Data race condition (MISSING_LOCK)
missing_lock: Accessing sets without holding lock sets_lock. Elsewhere, sets is written to with sets_lock held 2 out of 3 times.
Break out RPM, Debian, and Ubuntu package installation into their own
pages.
Also break out other distributions like "Arch" into an "Other" section
with a note about how those packages are not supported by the OISF.
Ticket: #6252
Ticket: #6069
Remove the half finished support for accepting a table returned from a
Lua rule's match function. This is not documented, not tested, and not
really implemented.
Also, use lua_tointeger to get the return value from the match function
as an integer instead of a float.
Ticket: #6941
Coverity did detect that the cleaning code is only reached with
Dataset *set being initialized so the check is useless.
** CID 1649392: Null pointer dereferences (REVERSE_INULL)
/src/datasets-context-json.c: 719 in DatajsonGet()
>>> Null-checking "set" suggests that it may be null, but it has
already been dereferenced on all paths leading to the check.
** CID 1649391: Null pointer dereferences (REVERSE_INULL)
/src/datasets.c: 526 in DatasetGet()
>>> Null-checking "set" suggests that it may be null, but it has
already been dereferenced on all paths leading to the check.
tzname is a POSIX variable, WIN32 has prefixed many POSIX variables
with "_". While Mingw64 supports both, UCRT64 emits a compiler warning
on the usage of "tzname".
This triggered a rather large clang-format update.
Philippe Antoine
Fupeng Zhao
Jeff Lucovsky
Lukas Sismis
Victor Julien
Jason Ish
Juliana Fajardini
Eric Leblond
Boris Tonofa