Calling util::fmt() from DoUpdate() of a thread is not safe as it is
using a statically allocated buffer and other threads or the main
thread may concurrently modify this buffer.
This was found by observing the scripts.base.frameworks.config.several-files
failing once in a blue moon (1/250 sometimes 1/1000 runs) with messages like
"Failed to compile regex: Parenthesis is not closed.":
scripts.base.frameworks.config.several-files ...
> btest-bg-run zeek zeek -b %INPUT
> btest-bg-wait 10
... scripts.base.frameworks.config.several-files failed
% 'btest-bg-wait 10' failed unexpectedly (exit code 1)
% cat .stderr
The following processes did not terminate:
zeek -b /home/awelzel/corelight-oss/zeek/testing/btest/.tmp/scripts.base.frameworks.config.several-files/several-files.zeek
-----------
<<< [3667265] zeek -b /home/awelzel/corelight-oss/zeek/testing/btest/.tmp/scripts.base.frameworks.config.several-files/several-files.zeek
error: ../configfile1/Input::READER_CONFIG: Failed to compile regex: Parenthesis is not closed.
received termination signal
>>>
* origin/topic/timw/1129-slash-s-patterns:
Add support for /s modifier to RE matcher and parser
Code cleanup in RE_Matcher code
Add basic unit tests for RE_Matcher
Add /s modifier to parser for patterns
Due to the asynchronous behavior of the input framework and broker
communication, change handlers were previously called even after
zeek_done() event processing completed and also broker shutdown.
Accessing broker store handles within change handlers this late
triggered invalid Broker store handle messages:
error in ././my_option_store.zeek, line 13: invalid Broker store handle (Broker::put(Test::store, to_any_coercemy_option, to_any_coerceTest::new_value, 0 secs) and broker::store::{})
Fixes#2010
A flood of DHCP traffic can result if very large log entries consisting
of many uids and/or msg_types. Such large log entries can disrupt a SIEM
ingestion pipeline. This change forcing a log entry to be written when
the number of uids or the number of msg_Types exceed a certain value.
The values are treated as options for easy configuration.
Add the `pdu_type` field to Modbus over TCP logs to indicate whether the Modbus
message was a request or a response. Due to the client/server nature of Modbus
over TCP/IP, all messages from the TCP session originator are requests, while
all messages from the TCP session responder are responses.
Adding this information to the default log surfaces protocol metadata in a way
that doesn't require users to understand the Modbus over TCP protocol.
* origin/topic/timw/1628-duplicate-record-field:
Add comments for specialized versions of util::split
Make char*/wchar_t* split methods use string_view/wstring_view
GH-1628: Return an error for duplicate record field names
Fix a bug with splitting strings in Ascii input reader
Iterator and looping cleanup in Ascii input reader
Add util::split methods for splitting strings
