When a Tracker is set up for a IPID, frags come in for it and it's
reassembled and complete, the `DefragTracker::remove` flag is set. This
is mean to tell the hash cleanup code to recyle the tracker and to let
the lookup code skip the tracker during lookup.
A logic error lead to the following scenario:
1. there are sufficient frag trackers to make sure the hash table is
filled with trackers
2. frags for a Packet with IPID X are processed correctly (X1)
3. frags for a new Packet that also has IPID X come in quickly after the
first (X2).
4. during the lookup, the frag for X2 hashes to a hash row that holds
more than one tracker
5. as the trackers in hash row are evaluated, it finds the tracker for
X1, but since the `remove` bit is not checked, it is returned as the
tracker for X2.
6. reassembly fails, as the tracker is already complete
The logic error is that only for the first tracker in a row the `remove`
bit was checked, leading to reuse to a closed tracker if there were more
trackers in the hash row.
Ticket: #7042.
use brew instead of pip
limit the number of jobs for make
set a prefix where we can install
use brew flags for library finding
(cherry picked from commit 47a1502dbb)
Ticket: 7013
Done consistently for all protocols
This may change some protocols behaviors which failed early
if they found there was not enough data...
(cherry picked from commit 37a9003736)
As this triggers rustc 1.78
unsafe precondition(s) violated: slice::from_raw_parts requires
the pointer to be aligned and non-null,
and the total size of the slice not to exceed `isize::MAX`
Ticket: 7013
inspired from commit 5dc8dea869
Caused by:
failed to parse manifest at `/builds/inliniac/suricata-ci/suricata/rust/vendor/num-traits/Cargo.toml`
Caused by:
failed to parse the `edition` key
Caused by:
supported edition values are `2015` or `2018`, but `2021` is unknown
Lock to last working version 0.2.18.
Ticket: #7007.
This commit modifies the logic used to determine the disposition of a
flow/packet.
If the rule doesn't require a stream and only contains properties for
packet matching, then the alert is not marked as applying to the
flow and hence, the flow won't be dropped.
Issue: 5578
Ticket: 6900
And thus avoid DOS by logging a request using a compressed
header block repeated many times and having a long value...
(cherry picked from commit 03442c9071)
Ticket: 6892
As HTTP hpack header compression allows one single byte to
express a previously seen arbitrary-size header block (name+value)
we should avoid to copy the vectors data, but just point
to the same data, while reamining memory safe, even in the case
of later headers eviction from the dybnamic table.
Rust std solution is Rc, and the use of clone, so long as the
data is accessed by only one thread.
(cherry picked from commit 390f09692e)
Ticket: 6889
To avoid regexp dos with too much backtracking.
This is already done on pcre keyword, and pcrexform transform.
We use the same default limits for rules parsing.
(cherry picked from commit 316cc528f7)
Using pcre1 in master6
The list of fragments may still contain overlaps, so adding up the
fragment lengths is flawed. Instead track the largest size of
contiguous data that can be re-assembled.
Bug: #6675
(cherry picked from commit d226d0a3fc)
Fix the BSD policy case where a subsequent fragment starts before an
original fragment and overlaps the beginning of the original
fragment. In this case the overlapping data from the new fragment is
preferred.
Suricata was preferring the data from the original fragment, but it
should only do that when the original fragment has an offset <= to the
new fragment.
- Adds tests for this case
Bug: #6669
(cherry picked from commit f1709ea551)
Instead of breaking the loop when the current fragment does not have
any more fragments, set a flag and continue to the next fragment as
the next fragment may have data that occurs before this fragment, but
overlaps it.
Then break if the next fragment does not overlap the previous.
Bug: #6668
(cherry picked from commit d0fd078250)
Eve's packet_info.linktype should correctly indicated what the `packet`
field contains. Until now it was using DLT_RAW even if Ethernet or other
L2+ headers were present.
This commit records the datalink of the packet creating the first
fragment, which can include the L2+ header data.
Bug: #6887.
(cherry picked from commit 49c67b2bb1)
error: creating a mutable reference to mutable static is discouraged
--> src/mqtt/mqtt.rs:752:23
|
752 | let max_msg_len = &mut MAX_MSG_LEN;
| ^^^^^^^^^^^^^^^^ mutable reference to mutable static
|
= note: for more information, see issue #114447 <https://github.com/rust-lang/rust/issues/114447>
= note: this will be a hard error in the 2024 edition
= note: this mutable reference has lifetime `'static`, but if the static gets accessed (read or written) by any other means, or any other reference is created, then any further use of this mutable reference is Undefined Behavior
Ticket: 6883
error: field `0` is never read
--> src/asn1/mod.rs:36:14
|
36 | BerError(Err<der_parser::error::BerError>),
| -------- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| |
| field in this variant
|
(cherry picked from commit 02f2fb8833)
Ticket: 6878
Follow up on 15649424a7
When adding many sequence nodes, either from start or scalar event
We add "sequence nodes" whose name is an integer cf sequence_node_name
and then run ConfNodeLookupChild to see if it had been already set
(from the command line cf comment in the code)
And ConfNodeLookupChild iterates the whole linked list...
1. We add node 1
2. To add node 2, we check if node 1 equals this new node
3. To add node 3, we check if nodes 1, or 2 equals this new node's name
And so on...
This commits avoids these checks ig the list is empty at the beginning
(cherry picked from commit 240e068b81)
Ticket: 6876
Do not backport try_string_from_bytes as it uses try_reserve
And just use string_from_bytes instead
Fixes: b9963b3e29 ("ssh: limit length for banner logs")
Ticket: 6799
When we find an overlong banner, we get into the state just
waiting for end of line, and we just want to skip the bytes
until then.
Returning AppLayerResult::incomplete made TCP engine retain
the bytes and grow the buffer that we parsed again and again...
(cherry picked from commit 271ed2008b)
Ticket: #6305
When running FlowWorkerStreamTCPUpdate, one of the dequeued packet
may set the flow action to drop, without updating the not-pseudo
packet action, as is done usually with a previous call to
FlowHandlePacketUpdate
(cherry picked from commit 4c4f7ff1a2)
Fix memory leak at util-decode-mime:MimeDecInitParser, which
root cause is not-freeing allocated memory for mimeMsg
Bug: #6745
(cherry picked from commit 231c892bef)
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: #6767.
Co-authored-by: Shivani Bhardwaj <shivani@oisf.net>
Ticket: 6481
Instead of just setting the old transactions to a drop state so
that they get later cleaned up by Suricata, fail creating new ones.
This is because one call to app-layer parsing can create many
transactions, and quadratic complexity could happen in one
single app-layer parsing because of find_or_create_tx
(cherry picked from commit 80abc22f64)
Ticket: 6477
So as to avoid ending up with too many empty transactions.
This happens when Suricata sees a DATA command in the current
transaction but did not have a confirmation response for it.
Then, if Suricata receives another DATA command, it will
create another new transaction, even if the previous one
is empty. And so, a malicious client can create many empty
transactions by just sending a repeated amount of DATA commands
without having a confirmation code for them.
Suricata cannot use state->current_command == SMTP_COMMAND_DATA
to prevent this attack and needs to resort to a new boolean
is_data because the malicious client may send another dummy command
after each DATA command.
This patch leaves only one call to SMTPTransactionCreate
(cherry picked from commit 61f2e4e1e5)
Unlike the original commit, this fix just sets a limit but does not
expose it as a configurable option.
Ticket: #6477
(cherry picked from commit 8f73a0ac55)