Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

next/448/70x/20240523/v1 #11135

Merged
merged 15 commits into from
May 24, 2024

Conversation

jlucovsky and others added 15 commits May 23, 2024 17:27
Issue: 6861

Without this commit, disabling rule profiling via suricatasc's command
'ruleset-profile-stop' may crash because profiling_rules_entered becomes
negative.

This can happen because
- There can be multiple rules evaluated for a single packet
- Each rule is profiled individually.
- Starting profiling is gated by a configuration setting and rule
  profiling being active
- Ending profiling is gated by the same configuration setting and
  whether the packet was marked as profiling.

The crash can occur when a rule is being profiled and rule profiling
is then disabled after one at least one rule was profiled for the packet
(which marks the packet as being profiled).

In this scenario, the value of profiling_rules_entered was
not incremented so the BUG_ON in the end profiling macro trips
because it is 0.

The changes to fix the problem are:
- In the profiling end macro, gate the actions taken there by the same
  configuration setting and use the profiling_rues_entered (instead of
  the per-packet profiling flag). Since the start and end macros are
  tightly coupled, this will permit profiling to "finish" if started.
- Modify SCProfileRuleStart to only check the sampling values if the
  packet hasn't been marked for profiling already. This change makes all
  rules for a packet (once selected) to be profiled (without this change
  sampling is applied to each *rule* that applies to the packet.

(cherry picked from commit bf5cfd6)
In offline mode, a timestamp is kept per thread, and the lowest
timestamp of the active threads is used. This was also considering the
non-packet threads, which could lead to the used timestamp being further
behind that needed. This would happen at the start of the program, as
the non-packet threads were set up the same way as the packet threads.

This patch both no longer sets up the timestamp for non-packet threads
as well as not considering non-packet threads during timestamp
retrieval.

Fixes: 6f56014 ("time: improve offline time handling")

Bug: OISF#7034.
(cherry picked from commit 5455799)
The on-disk pcap pkthdr is 16 bytes. This was calculated using
`sizeof(struct pcap_pkthdr)`, which is 24 bytes on 64 bit Linux. On
Macos, it's even worse, as a comment field grows the struct to 280
bytes.

Address this by hardcoding the value of 16.

Bug: OISF#7037.
(cherry picked from commit 6c937a9)
Bug: https://redmine.openinfosecfoundation.org/issues/6782

Callers to these allocators often use ``sc_errno`` to provide context of
the error. And in the case of the above bug, they return ``sc_errno``,
but as it has not been set ``sc_errno = 0; == SC_OK``.

This patch simply sets this variable to ensure there is context provided
upon error.

(cherry picked from commit fc2e49f)
In the default config iface bypass support is not enabled,
and storage API not initialized for it. Using it will lead to a crash.

This commit first checks if the device storage API is initialized.

Bug: OISF#7022.
(cherry picked from commit bc2dfe4)
Commands would leave use_cnt incremented, never decrementing them. This
would lead to a asserting triggering at shutdown.

Bug: OISF#7020.
(cherry picked from commit d02c57b)
Support compressed proto and optional HDLC header.

Bug: OISF#6942.
(cherry picked from commit 68092ff)
As we now support variable size headers, we can't use the old pointer.

Replace with a flag.

(cherry picked from commit 6067955)
No users of the pointer anymore, so remove it.

(cherry picked from commit 7e3f071)
Recognize PPP_CCP, PPP_CBCP and PPP_COMP_DGRAM.

Does not implement decoders for these record types, so these
are logged as unsupported types. Was "wrong_type" before.

(cherry picked from commit 516441b)
** CID 1596376:    (CONSTANT_EXPRESSION_RESULT)
/src/decode-ppp.c: 64 in DecodePPPCompressedProto()
/src/decode-ppp.c: 55 in DecodePPPCompressedProto()

________________________________________________________________________________________________________
*** CID 1596376:    (CONSTANT_EXPRESSION_RESULT)
/src/decode-ppp.c: 64 in DecodePPPCompressedProto()
58             case 0x57: { /* PPP_IPV6 */
59                 if (unlikely(len < (data_offset + IPV6_HEADER_LEN))) {
60                     ENGINE_SET_INVALID_EVENT(p, PPPIPV6_PKT_TOO_SMALL);
61                     return TM_ECODE_FAILED;
62                 }
63                 DEBUG_VALIDATE_BUG_ON(len < data_offset);
>>>     CID 1596376:    (CONSTANT_EXPRESSION_RESULT)
>>>     "65535 /* 32767 * 2 + 1 */ < (uint16_t)(len - data_offset)" is always false regardless of the values of its operands. This occurs as the logical first operand of "?:".
64                 uint16_t iplen = MIN(USHRT_MAX, (uint16_t)(len - data_offset));
65                 return DecodeIPV6(tv, dtv, p, pkt + data_offset, iplen);
66             }
67             case 0x2f: /* PPP_VJ_UCOMP */
68                 if (unlikely(len < (data_offset + IPV4_HEADER_LEN))) {
69                     ENGINE_SET_INVALID_EVENT(p, PPPVJU_PKT_TOO_SMALL);
/src/decode-ppp.c: 55 in DecodePPPCompressedProto()
49             case 0x21: { /* PPP_IP */
50                 if (unlikely(len < (data_offset + IPV4_HEADER_LEN))) {
51                     ENGINE_SET_INVALID_EVENT(p, PPPVJU_PKT_TOO_SMALL);
52                     return TM_ECODE_FAILED;
53                 }
54                 DEBUG_VALIDATE_BUG_ON(len < data_offset);
>>>     CID 1596376:    (CONSTANT_EXPRESSION_RESULT)
>>>     "65535 /* 32767 * 2 + 1 */ < (uint16_t)(len - data_offset)" is always false regardless of the values of its operands. This occurs as the logical first operand of "?:".
55                 uint16_t iplen = MIN(USHRT_MAX, (uint16_t)(len - data_offset));
56                 return DecodeIPV4(tv, dtv, p, pkt + data_offset, iplen);
57             }
58             case 0x57: { /* PPP_IPV6 */
59                 if (unlikely(len < (data_offset + IPV6_HEADER_LEN))) {
60                     ENGINE_SET_INVALID_EVENT(p, PPPIPV6_PKT_TOO_SMALL);

(cherry picked from commit dc5b78e)
Ticket: 6846

This led to packet rules logging irrelevant app-layer data

(cherry picked from commit 910f6af)
Ticket: 6846
(cherry picked from commit 2b4e102)
When we only have stream matches.

Ticket: 6846

This solves the case where another transaction was created
by parsing data in the other direction, before running the
detection.

Like
1. get data in direction 1
2. acked data: parse it, but do not run detection in dir 1
3. other data in direction 2
4. other data acked : parse it and create new tx,
then run detection for direction 1 with data from first packet

(cherry picked from commit 7274ad5)
Ticket: 6973

Completes commit 2b4e102

(cherry picked from commit 9e01956)
Copy link
Contributor

@jufajardini jufajardini left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Commits picked seem to match the ones from the mentioned and approved PRs.

Copy link
Contributor

@catenacyber catenacyber left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like a good staging branch for the mentioned PRs

@suricata-qa
Copy link

WARNING:

field baseline test %
SURI_TLPR1_stats_chk
.decoder.event.ppp.wrong_type 2862 0 -
.decoder.event.ppp.unsup_proto 931 3772 405.16%

Pipeline 20754

@victorjulien
Copy link
Member Author

@ct0br0 this needs the same qa baseline update as here #10844 (comment)

@victorjulien victorjulien merged commit 930eadd into OISF:main-7.0.x May 24, 2024
42 checks passed
@victorjulien victorjulien deleted the next/448/70x/20240523/v1 branch May 24, 2024 04:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
7 participants