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

Check size of tcpFragmentList before delete fragment #1346

Open
wants to merge 18 commits into
base: dev
Choose a base branch
from

Conversation

MCredbear
Copy link

Fragment might be delete after calling m_OnMessageReadyCallback (eg. call TcpReassembly::closeConnection in m_OnMessageReadyCallback), so we need to check if it's already deleted .

@MCredbear MCredbear requested a review from seladb as a code owner March 21, 2024 14:54
Copy link

codecov bot commented Mar 22, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 82.37%. Comparing base (e48be80) to head (2d1ac80).

Additional details and impacted files
@@            Coverage Diff             @@
##              dev    #1346      +/-   ##
==========================================
+ Coverage   82.34%   82.37%   +0.03%     
==========================================
  Files         163      163              
  Lines       20937    20939       +2     
  Branches     7906     7910       +4     
==========================================
+ Hits        17241    17249       +8     
+ Misses       3025     3017       -8     
- Partials      671      673       +2     
Flag Coverage Δ
alpine317 72.39% <100.00%> (-0.03%) ⬇️
fedora37 72.40% <100.00%> (-0.03%) ⬇️
macos-12 61.41% <84.21%> (+<0.01%) ⬆️
macos-13 60.44% <84.21%> (-0.01%) ⬇️
macos-14 60.44% <84.21%> (-0.01%) ⬇️
macos-ventura 61.47% <84.21%> (-0.01%) ⬇️
mingw32 70.28% <100.00%> (-0.03%) ⬇️
mingw64 70.29% <100.00%> (-0.04%) ⬇️
npcap 83.36% <100.00%> (+<0.01%) ⬆️
rhel93 72.44% <100.00%> (-0.01%) ⬇️
ubuntu1804 74.75% <100.00%> (+0.01%) ⬆️
ubuntu2004 73.20% <100.00%> (-0.01%) ⬇️
ubuntu2204 72.24% <100.00%> (-0.01%) ⬇️
ubuntu2204-icpx 58.96% <84.21%> (-0.02%) ⬇️
unittest 82.37% <100.00%> (+0.03%) ⬆️
windows-2019 83.39% <100.00%> (+0.03%) ⬆️
windows-2022 83.41% <100.00%> (+0.03%) ⬆️
winpcap 83.37% <100.00%> (+0.05%) ⬆️
xdp 59.09% <0.00%> (-0.01%) ⬇️
zstd 73.84% <100.00%> (+0.05%) ⬆️

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

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@MCredbear
Copy link
Author

I add a new function to specially test that case, appologize for the ugly code

Copy link
Owner

Choose a reason for hiding this comment

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

In order for the test to run you need to add PTF_RUN_TEST here:

PTF_RUN_TEST(TestXdpDeviceInvalidConfig, "xdp");

// tcpReassemblyTestManuallyCloseConnOnMesgReady()
// ~~~~~~~~~~~~~~~~~~~

static bool tcpReassemblyTestManuallyCloseConnOnMesgReady(const std::vector<pcpp::RawPacket>& packetStream, TcpReassemblyMultipleConnStatsWithReassembly& results, bool monitorOpenCloseConns, bool closeConnsManually)
Copy link
Owner

Choose a reason for hiding this comment

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

I think we can make this method simpler - I don't think that monitorOpenCloseConns and closeConnsManually are needed...

flowKeysList.clear();
}

pcpp::TcpReassembly *tcpReassmbly = nullptr;
Copy link
Owner

Choose a reason for hiding this comment

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

Maybe instead of duplicating the entire struct we can just inherit from TcpReassemblyMultipleConnStats and add pcpp::TcpReassembly *tcpReassmbly?
Or another option is to add pcpp::TcpReassembly *tcpReassmbly to TcpReassemblyMultipleConnStats

@MCredbear
Copy link
Author

图片
图片
Sorry, it occurs error again after I deploy my project in a 20Gb/s network..... Currently I'm still figuring what causes this.

@tigercosmos
Copy link
Collaborator

图片 图片 Sorry, it occurs error again after I deploy my project in a 20Gb/s network..... Currently I'm still figuring what causes this.

are you able to reproduce it? adding the root cause in the test is helpful for the edge cases.

@MCredbear
Copy link
Author

图片 图片 Sorry, it occurs error again after I deploy my project in a 20Gb/s network..... Currently I'm still figuring what causes this.

are you able to reproduce it? adding the root cause in the test is helpful for the edge cases.

Yes, and my new commit fixes it, thought I think this error shouldn't be caused...

@davidbolvansky
Copy link

davidbolvansky commented Apr 11, 2024

I am using TcpReassembly and it crashes with double free / invalid pointer in checkOutOfOrderFragments, but only on ARM, interestingly.

Looking at this, it seems this PR should fix crashes I see. I have a pcap with recorded traffic, but unfortunelly I cannot share it. But I could help you with testing.

@tigercosmos
Copy link
Collaborator

I am using TcpReassembly and it crashes with double free / invalid pointer in checkOutOfOrderFragments, but only on ARM, interestingly.

Looking at this, it seems this PR should fix crashes I see. I have a pcap with recorded traffic, but unfortunelly I cannot share it. But I could help you with testing.

That would be great, would you like to help test the PR with your pcap file on the ARM machine?

@davidbolvansky
Copy link

davidbolvansky commented Apr 13, 2024

Yes, the bug happens when you call closeConnection from OnMessageReadyCallback. Use build with address sanitizers (or valgrind?).

I tried you branch and I did not see crash

@seladb

@tigercosmos
Copy link
Collaborator

@davidbolvansky could you please furnish a concise reproducible code sample illustrating the issue you're encountering?

@davidbolvansky
Copy link

As I said the bug happens when you call tcpReassembly.closeConnection(connData.flowKey) from OnMessageReadyCallback - OnMessageEndCallback is called for first time.

Then OnMessageEndCallback is called again, due normal fin. This second invocation triggers double free.

@@ -64,6 +64,7 @@ PTF_TEST_CASE(TestTcpReassemblySanity);
PTF_TEST_CASE(TestTcpReassemblyRetran);
PTF_TEST_CASE(TestTcpReassemblyMissingData);
PTF_TEST_CASE(TestTcpReassemblyOutOfOrder);
PTF_TEST_CASE(TestTcpReassemblyOutOfOrderManuallyCloseConnOnMesgReady);
Copy link
Owner

Choose a reason for hiding this comment

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

Can we make the test name shorter?
Maybe: TestTcpReassemblyOOOCloseConn

Copy link
Author

Choose a reason for hiding this comment

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

Is TestTcpReassemblyOutOfOrderWithManualClose fine?

Copy link
Owner

@seladb seladb Apr 21, 2024

Choose a reason for hiding this comment

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

We should probably change that, but we currently have a hard-coded limit of 35 characters for test names, here is an example:

std::cout << std::left << std::setw(35) << #TestName << ": PASSED" << std::endl; \

Tests that have a longer name will result in a weird UI print, something like:

...
...
TestTcpReassemblyMalformedPkts     : PASSED
TestTcpReassemblyMultipleConns     : PASSED
TestTcpReassemblyIPv6              : PASSED
TestTcpReassemblyIPv6MultConns     : PASSED
TestTcpReassemblyIPv6_OOO          : PASSED
TestTcpReassemblyCleanup           : PASSED
TestTcpReassemblyMaxOOOFrags       : PASSED
TestTcpReassemblyMaxSeq            : PASSED
TestTcpReassemblyDisableOOOCleanup : PASSED
TestTcpReassemblyOutOfOrderWithManualClose: PASSED
...

@seladb
Copy link
Owner

seladb commented Apr 19, 2024

@MCredbear can you please address the remaining comments so we can get the PR merged?

@seladb
Copy link
Owner

seladb commented Apr 21, 2024

@seladb
Copy link
Owner

seladb commented Apr 26, 2024

@MCredbear the new test fails in CI 😕

@MCredbear
Copy link
Author

Emm, I don't know what causes the new CI test error

@egecetin
Copy link
Collaborator

@MCredbear In output side there are three different HTTP payloads with Content-Length 2248, 5261 and 6634. But for expected side there are four different HTTP payloads with Content-Length 2428, 5261, 6634 and 6649. So, it looks like the last request/reply pattern does not exist. If it is expected behavior, you should change the expected data.

@@ -64,6 +64,7 @@ PTF_TEST_CASE(TestTcpReassemblySanity);
PTF_TEST_CASE(TestTcpReassemblyRetran);
PTF_TEST_CASE(TestTcpReassemblyMissingData);
PTF_TEST_CASE(TestTcpReassemblyOutOfOrder);
PTF_TEST_CASE(TestTcpReassemblyOOOWithManualClose);
Copy link
Collaborator

Choose a reason for hiding this comment

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

what is "OOO"?

Copy link
Owner

Choose a reason for hiding this comment

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

OOO == Out Of Order

Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't like the abbreviation, not straightforward, I would recommend TestTcpReassemblyOutOfOrderWithManualClose

Copy link
Owner

Choose a reason for hiding this comment

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

The problem is that we currently have a limit of 35 chars per test (you can see it everywhere in PcppTestFramework.h so longer test names will look misaligned when running them. Perhaps we can remove this limitation and automatically detect the longest test name, but I'm not sure it'd be straightforward to do 🤔

We can also extend the 35 limit to a larger number...

Copy link
Collaborator

Choose a reason for hiding this comment

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

@seladb maybe we should increase the number? TestTcpReassemblyOutOfOrderWithManualClose length is 42, so I guess changing it to 50 is enough.

tcpReassembly->reassemblePacket(packet);
}

//for(TcpReassemblyMultipleConnStats::Stats::iterator iter = results.stats.begin(); iter != results.stats.end(); iter++)
Copy link
Collaborator

Choose a reason for hiding this comment

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

forget to remove?

@tigercosmos
Copy link
Collaborator

@MCredbear would you like to finish the PR?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants