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/148/60x/20231017/v1 #9643

Merged
merged 5 commits into from Oct 17, 2023

Conversation

victorjulien
Copy link
Member

jlucovsky and others added 5 commits October 14, 2023 13:45
Issue: 4624

Handle negative post_offset values that jump before the buffer as though
they refer to the buffer start.

(cherry picked from commit 2bf9d0f)
so that we get one compatible with MSRV
Pseudo packets originating in the flow worker do not need to leave the
flow worker. Putting those in the ThreadVars::decode_pq will make them
be evaluated by the next steps in the pipeline, but those will all
ignore pseudo packets.

Instead, this patch returns them to the packet pool, while still honoring
the IPS verdict logic.

(cherry picked from commit 3247e39)
(cherry picked from commit 25396dc)
When the decoders encounter multiple layers of tunneling, multiple tunnel
packets are created. These are then stored in ThreadVars::decode_pq, where
they are processed after the current thread "slot" is done. However, due
to a logic error, the tunnel packets after the first, where not called
for the correct position in the packet pipeline. This would lead to these
packets not going through the FlowWorker module, so skipping everything
from flow tracking, detection and logging.

This would only happen for single and workers, due to how the pipelines
are constructed.

The "slot" holding the decoder, would contain 2 packets in
ThreadVars::decode_pq. Then it would call the pipeline on the first
packet with the next slot of the pipeline through a indirect call to
TmThreadsSlotVarRun(), so it would be called for the FlowWorker.
However when that first (the most inner) packet was done, the call
to TmThreadsSlotVarRun() would again service the ThreadVars::decode_pq
and process it, again moving the slot pointer forward, so past the
FlowWorker.

This patch addresses the issue by making sure only a "decode" thread
slot will service the ThreadVars::decode_pq, thus never moving the
slot past the FlowWorker.

Bug: OISF#6402.
(cherry picked from commit 15947f2)
@victorjulien victorjulien requested review from jasonish and a team as code owners October 17, 2023 17:30
@suricata-qa
Copy link

Information: QA ran without warnings.

Pipeline 16170

@victorjulien victorjulien merged commit 0ada1d5 into OISF:master-6.0.x Oct 17, 2023
25 checks passed
This was referenced Oct 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
5 participants