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/415/v6 #4119

Merged
merged 6 commits into from Aug 23, 2019
Merged

Next/415/v6 #4119

merged 6 commits into from Aug 23, 2019

Conversation

victorjulien
Copy link
Member

Fix for https://redmine.openinfosecfoundation.org/issues/2841
Backports of #4105 & #4052
Backport of pcap breakloop fixes.
#4079

PRScript output (if applicable):
Passed.

regit and others added 6 commits August 21, 2019 18:05
Fix the following warnings by compiler,
(1) warning: use of deprecated item 'take_until_s': Please use `take_until` instead
(2) warning: `...` range patterns are deprecated

For the second warning, the builtin lint
"ellipsis_inclusive_range_pattern" has been added which causes the
following warning to show up with rustc 1.24.

warning: unknown lint: `ellipsis_inclusive_range_patterns`
  --> /home/travis/build/OISF/suricata/suricata-5.0.0-dev/rust/src/lib.rs:18:10
   |
18 | #![allow(ellipsis_inclusive_range_patterns)]
   |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: #[warn(unknown_lints)] on by default

Since there is no other way to fix this, the above warning shall stay.
We need to take care of modifying this if and when the support for 1.24
as MSRV is dropped.
The capture threads can receive packets from the flow manager in their
Threadvars::stream_pq packet queue. This mechanism makes sure the packets
the flow manager injects into the engine are processed by the correct
worker thread.

If the capture thread(s) would not receive packets for a long time, the
Threadvars::stream_pq would not be checked and processed. This could
lead to packet pool depletion in the flow manager. It would also lead
to flows not being timed out/logged until either packets started flowing
again or until the engine was shut down.

The scenario is more likely to happen in a test (e.g. replay) but could
also delay logging on low traffic sensors.
ICMP unreachable errors are linked to the flow they send an error for.
This would lead to the detection engine calling the TX inspection
engines on them.

The stream inspect engine would default to a match for non-UDP
and non-TCP as for ICMP we're not expected to use a TX inspect engine
for stream data.

This all would lead to a false positive match.

This patch fixes this by making sure the TX engines are not called if
the packet protocol and flow protocol are not the same.

Bug OISF#2841.
@victorjulien victorjulien merged commit 6f5b81c into OISF:master-4.1.x Aug 23, 2019
@victorjulien victorjulien deleted the next/415/v6 branch September 23, 2019 09:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
4 participants