Skip to content

detect: investigation on single-pkt flows inspection (5180) - v3#14747

Closed
jufajardini wants to merge 3 commits intoOISF:mainfrom
jufajardini:bug-5180-01-single-pkt/v3
Closed

detect: investigation on single-pkt flows inspection (5180) - v3#14747
jufajardini wants to merge 3 commits intoOISF:mainfrom
jufajardini:bug-5180-01-single-pkt/v3

Conversation

@jufajardini
Copy link
Contributor

@jufajardini jufajardini commented Feb 4, 2026

Link to ticket: https://redmine.openinfosecfoundation.org/issues/
https://redmine.openinfosecfoundation.org/issues/5180

Previous PR: #14704

Describe changes:

  • following Victor's suggestion for a more generic approach in flagging the packet as part of a mid-stream session

To consider:
I assumed that, with this approach, we shouldn't need to flag the packet stream as established in the TCP fast open scenario (done here

p->flags |= PKT_STREAM_EST;
), either (as this would cover for it, too). However, attempting to change this resulted in SV test tcp-fastopen-13 failing -- and... I'm not sure that's to be expected? -- the failure is that the alert will trigger with pcap_cnt 3, instead of pcap_cnt 1 Could this be related to this being non-IPS mode?
For now, then, I have not removed that bit. But this might need further investigation -- for this patch, or for a follow-up work?

Provide values to any of the below to override the defaults.
SV_BRANCH=OISF/suricata-verify#2901

During initialization, the engine reports how many rules were loaded, as
well as which types. Pkt-only or stream-pkt rules would cause a "hole"
in such stats, as they're not counted.
Commit 497394e removed inspection of app-proto txs for packets
without an established TCP connection. But this meant that the
first packet seen in a session pick mid-stream could go without
inspection (previous bug 5510 seemed to point towards this behavior,
too).
If a flow has more packets, the stream will be inspected as part of
the upcoming packets and this would go unnoticed. In a single-packet
flow, however, the inspection for the packed would be skipped. Although
this might not affect alerts -- as they could be processed as part of
the flow timeout logic, the actual traffic could be evaded in IPS, in
case of a drop rule.

From the above, the most visible scenario is when there is only one packet on the flow,
as then the engine doesn't have "more time" to pick-up real-packets to
inspect for that given flow. But certain tests show that this can also
happen for more than one packet scenarios: there will be one less drop
event, or traffic from a packet that should have been already dropped
will be logged.

This led to the possibility of a real packet not being blocked, in IPS,
or matched against rules, as the corresponding portion of the stream
was only inspected later, as part of the stream/flow-timeout logic.

To ensure that we correctly flag the first packet seen for a given mid-stream
session, we must check for the session state *after* we have dealt with
TCP flags and state.

Related to
Bug OISF#5510

As part of
Bug OISF#5180
Comment on lines -5807 to -5810

if (ssn->state >= TCP_ESTABLISHED) {
p->flags |= PKT_STREAM_EST;
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Should this change go in a separate commit?

Copy link
Member

Choose a reason for hiding this comment

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

Yeah I think that is cleaner.

@codecov
Copy link

codecov bot commented Feb 4, 2026

Codecov Report

❌ Patch coverage is 90.00000% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 82.16%. Comparing base (c1d6958) to head (0c44f3f).
⚠️ Report is 16 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main   #14747      +/-   ##
==========================================
- Coverage   82.17%   82.16%   -0.01%     
==========================================
  Files        1008     1008              
  Lines      263938   263952      +14     
==========================================
+ Hits       216878   216883       +5     
- Misses      47060    47069       +9     
Flag Coverage Δ
fuzzcorpus 60.20% <90.00%> (+<0.01%) ⬆️
livemode 18.72% <75.00%> (-0.01%) ⬇️
netns 18.54% <90.00%> (-0.02%) ⬇️
pcap 44.62% <90.00%> (-0.02%) ⬇️
suricata-verify 65.38% <90.00%> (+0.02%) ⬆️
unittests 59.35% <90.00%> (+<0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@suricata-qa
Copy link

Information: QA ran without warnings.

Pipeline = 29408

@victorjulien
Copy link
Member

Passed my QA. Ran this PR with SV PR OISF/suricata-verify#2901. Local pipeline 6175, run 1203.

Copy link
Member

@victorjulien victorjulien left a comment

Choose a reason for hiding this comment

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

I think this looks good. Can you do a non-draft PR with the commit split you suggested?

@jufajardini
Copy link
Contributor Author

Followed by: #14752

@jufajardini jufajardini closed this Feb 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants