Updated all cases where flow_config.prealloc was used in a division.
*** CID 1524506: Integer handling issues (DIVIDE_BY_ZERO)
/src/flow-manager.c: 858 in FlowManager()
852 "flow_spare_q status: %" PRIu32 "%% flows at the queue",
853 spare_pool_len, flow_config.prealloc,
854 spare_pool_len * 100 / flow_config.prealloc);
855
856 /* only if we have pruned this "emergency_recovery" percentage
857 * of flows, we will unset the emergency bit */
>>> CID 1524506: Integer handling issues (DIVIDE_BY_ZERO)
>>> In expression "spare_pool_len * 100U / flow_config.prealloc", division by expression "flow_config.prealloc" which may be zero has undefined behavior.
858 if (spare_pool_len * 100 / flow_config.prealloc > flow_config.emergency_recovery) {
859 emerg_over_cnt++;
860 } else {
861 emerg_over_cnt = 0;
862 }
Related to
Bug #5919
(cherry picked from commit 754d2803dd)
If flow.prealloc was set to zero in our yaml config, this led to
a floating point exception in the flow manager.
Bug: #5919.
(cherry picked from commit 5baa6c0024)
Remove the second occurrence of tree_id logging which appears to
always be a duplicate of the first tree_id logged, even though they
come from different data structures.
Issue: 5811
(cherry picked from commit 67baab573b)
In a case of the line buffer being over 255 bytes, the consumed bytes
would reset to 0 as it was uint8_t. Fix this integer overflow by setting
the type to uint32_t.
Redmine ticket: 5883
(cherry picked from commit c089bbb7d7)
If a file (read/write) SMB record has padding/trailing data
after the buffer being read or written, and that Suricata falls
in one case where it skips the data, it should skip until
the very end of the NBSS record, meaning it should also skip the
padding/trailing data.
Otherwise, an attacker may smuggle some NBSS/SMB record in this
trailing data, that will be interpreted by Suricata, but not
by the SMB client/server, leading to evasions.
Ticket: #5786
(cherry picked from commit 233ab11148)
When Suricata handles files over SMB, it does not wait for the
NBSS record to be complete, and can stream the payload to the
file... But it did not check the consistency of the SMB record
length being read or written against the NBSS record length.
This could lead to an evasion where an attacker crafts a SMB
write with a too big Length field, and then sends its evil
payload, even if the server returned an error for the write request.
Ticket: #5770
(cherry picked from commit c1b7befb18)
- Fix packet processing stall under high load when using netmap in IPS mode.
- Detect and generate Fatal Error exit for rare case when hardware NIC exposes
unmatched RX/TX queue counts. This is rare, but would result in some traffic
bypassing Suricata since it assumes NIC queue counts are symmetrical.
- Fix instance of missing unlock call for netmap device list when exiting due
to an error condition.
- Clean up existing code comments and add additional ones to better document
the new netmap v14 API code.
Adds a new field, "suricata-version" to the configuration file with
the major and minor version of the Suricata that generated the
configuration file.
This may be useful in the future for presenting warnings about
important changes, or even providing different defaults based on what
the user might expect.
Ticket: 5822
(cherry picked from commit c6c781ef67)
In pass/drop combinations where the pass rule took precendence over
the drop, a "drop" false positive could still be logged due to the
storing of the drop record in the packet drop alert store.
Bug: #5867.
(cherry picked from commit 09348564f0)
If urilen induced depth was set, later DetectContentPropagateLimits()
would apply a wrong depth setting, leading to a false negative in
some cases.
Bug: #5929.
(cherry picked from commit ba7db2583b)
Support case where there are multiple SYN retransmits, where
each has a new timestamp.
Before this patch, Suricata would only accept a SYN/ACK that
matches the last timestamp. However, observed behavior is that
the server may choose to only respond to the first. In IPS mode
this could lead to a connection timing out as Suricata drops
the SYN/ACK it considers wrong, and the server continues to
retransmit it.
This patch reuses the SYN/ACK queuing logic to keep a list
of SYN packets and their window, timestamp, wscale and sackok
settings. Then when the SYN/ACK arrives, it is first evaluated
against the normal session state. But if it fails due to a
timestamp mismatch, it will look for queued SYN's and see if
any of them match the timestamp. If one does, the ssn is updated
to use that SYN and the SYN/ACK is accepted.
Bug: #5856.
(cherry picked from commit 7bfee147ef)
Linux is slightly more permissive wrt timestamps than many
other OS'. To avoid many events/issues with linux hosts, add an
option to allow for this slightly more permissive behavior.
Ideally the host-os config would be used, but in practice this
setting is rarely set up correctly, if at all.
This option is enabled by default.
(cherry picked from commit 01b7ccc224)
RFC 2883 specifies a special use of SACKs to indicate a host has
received a segment it considers a spurious retransmission.
(cherry picked from commit d79a926085)
On every accepted packet in established state, update next_seq if
packet seq+len is larger than existing next_seq. This allows it to
catch up after large gaps that are filled again a bit later.
Bug: #5877.
(cherry picked from commit 76225bf9ac)
An ACK that ACK'd older data while still being in-window could
lead to FIN_WAIT1 to FIN_WAIT2 state transition. Detect this
case and generally harden the check.
Bug: #5877.
(cherry picked from commit 67af94f2e0)
If a in-tree segment was partly before base_seq the overlap detection
miscalculated the data offset. This lead to memcmp comparing the wrong
data.
Bug: #5881.
(cherry picked from commit cbcd70537a)
When a "stream starter" packet finds an existing TCP flow, the flow will be
evaluated for reuse.
The following scenario wasn't handled well:
1. Suricata starts after a tool has just stopped using lots of connections
(e.g. ab stress testing a webserver)
2. even though the client is closed already, the server is still doing
connection cleanup sending many FINs and later RSTs
3. Suricata creates flows for these packets, but no TCP sessions
4. client resumes testing, creating flows that have the same 5 tuple as the
flows created for the FIN/RST packets
5. Suricata refuses to "reuse" the flows as the condition "tcp flow w/o session"
is not considered valid for session reuse
6. new TCP connection is not properly tracked and evaluated in parsing and
detection
There may be other vectors into this, like a flow w/o session because of
memcap issues.
Bug: #5843.
(cherry picked from commit 93c9594dd8)
Fix payload_len calculation post removal of the condition that returned
error code if the length to the decode fn did not match the length of
header from the UDP packet.
Bug 5379
(cherry picked from commit f941ceae2b)
If the packet is shorter than IP payload length we no longer flag it as an
invalid UDP packet. UDP packet can be therefore shorter than IP payload.
Keyword "udp.hlen_invalid" became outdated as we no longer flag short UDP
packets as invalid. The keyword's evaluation remains the same.
Inspired by commit: d18e52ed93
Redmine ticket: #5793
In the default config these were enabled implicitly, as their `enabled`
field was commented out. This lead to warnings in the default config.
Ticket: #5299.
When the keyword config:logging disable,type tx is used,
OutputTxLog checks a flag to skip the transaction without logging
it, but AppLayerParserTransactionsCleanup waits for the
transaction to be marked as logged to clean it.
So, OutputTxLog now marks the tx as logged, so that it can
get cleaned away.
Ticket: #5456
(cherry picked from commit 0c0fcc9411)
Set the engine to ignore the stream.midstream-policy if stream.midstream
is enabled.
If we had both stream.midstream AND stream.midstream_policy enabled,
this could lead to midstream flows being dropped (or bypassed, or...)
instead of being accepted by the engine, as it was probably meant when
the user enabled midstream flows.
Bug #5765
(cherry picked from commit 8e9905e0d8)
cf https://redmine.openinfosecfoundation.org/issues/4125
This allows fuzz_applayerparser_parse to fuzz one specific
app-layer protocol based on the binary name, as is done
with the environment variable FUZZ_APPLAYER
That is if we rename/copy to fuzz_applayerparser_parse_smb,
it will fuzz only SMB protocol
This way, we can easily produce different fuzz targets for
each protocol in oss-fuzz
(cherry picked from commit e9b76a0e66)
Victor Julien
Juliana Fajardini
Jason Ish
Philippe Antoine
Shivani Bhardwaj
Philippe Antoine
Jeff Lucovsky
Bill Meeks
Eric Leblond
Lukas Sismis