Skip to content

Fix read overflow #1812

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.

Sign up for GitHub

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

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

Fix read overflow #1812

Changes from 2 commits
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
297891a
Fix read overflow
Marti2203 May 11, 2025
3ec7718
Merge branch 'dev' into fix-390004170
Marti2203 May 11, 2025
41b3812
Convert loging to error which is handled in BGPLayer
Marti2203 May 24, 2025
b342d18
Merge branch 'dev' into fix-390004170
seladb May 25, 2025
3d45189
Merge branch 'dev' into fix-390004170
Marti2203 Jun 13, 2025
0f94331
Rework to not reach exception case
Marti2203 Jun 15, 2025
e1c57c9
Merge branch 'dev' into fix-390004170
Marti2203 Sep 22, 2025
677d69f
Add Packet.h header and refacor condition
Marti2203 Sep 24, 2025
4891427
Fix fomatting
Marti2203 Sep 24, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions Packet++/src/RawPacket.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -136,6 +136,13 @@ namespace pcpp

void RawPacket::insertData(int atIndex, const uint8_t* dataToInsert, size_t dataToInsertLen)
{
// Check for overflow in the new length
if ((size_t)m_RawDataLen + dataToInsertLen < (size_t)m_RawDataLen)
{
PCPP_LOG_ERROR("RawPacket::insertData: dataToInsertLen causes overflow");
return;
}
Copy link
Collaborator

@Dimi1010 Dimi1010 May 11, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

Can we throw a std::length_error instead of just returning with a error message? The error message will not indicate the error condition to the caller.

Copy link
Owner

Choose a reason for hiding this comment

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

Will throwing an exception prevent the application from crashing? 🤔

This method was called in BgpLayer so we should probably think how to prevent it from being called with malformed data

Copy link
Collaborator

@Dimi1010 Dimi1010 May 12, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

You want a crash if overflow happens. Or at least you want an exception thrown to indicate the failure of the operation, and if the caller doesn't handle it up the call stack, then to crash. It isn't really possible to recover from the situation as the system has reached the limit of how much data can be stored inside a packet.

Silently continuing with just an error message in the log is worse as the program will assume the operation went fine and produce corrupted data down the line. This is exactly the type of improbable situation the exception mechanism was made to handle.

Copy link
Owner

Choose a reason for hiding this comment

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

I totally agree, however I don't think throwing an exception will resolve the OSS-Fuzz issue. We should probably throw an exception and fix the issue that caused it in BgpLayer

Copy link
Author

Choose a reason for hiding this comment

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

Hi, just to confirm - I will update the patch to throw an std::length_error . Would that be accepted by both of you? @Dimi1010 @seladb

Copy link
Collaborator

Choose a reason for hiding this comment

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

@seladb @Marti2203

Generally, I find exceptions are fine as long as they aren't used to dictate common control flow. The current mainstream compilers use an architecture that has a "zero cost" try-catch blocks if the exception isn't thrown. The tradeoff is a significant overhead if an exception is thrown, so you only want them thrown for rare events.

The current usage seems ok to me? How often are overflows expected to happen?

Copy link
Owner

Choose a reason for hiding this comment

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

In most cases, I wouldn't expect an exception to be thrown, however:

  • In applications that use PcapPlusPlus with an arbitrary payload (either to test malformed packet handling or because they generate a random payload), an exception can be thrown and we would like to avoid the cost of it
  • Most (or all?) of our critical path code doesn't catch exceptions and try to handle edge cases so they don't end up with exceptions. I think we should do the same here for consistency

Copy link
Author

Choose a reason for hiding this comment

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

Hi, I have been working on other things and have been checking out this PR again. I agree with sela's points and will prepare a patch after a confirmation from your side -

  • NO exception will be thrown in RawPacket, only it is logged and an error is returned. This is to ensure new clients of the code do not lead to a crash and code stylistically aligns with the rest.
  • Separately, will add a check for the error in the BGPLayer as it is the only client in the project that uses it.

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 still throw an error in insertData() but I would avoid try..catch in BgpLayer and instead check the sizes before calling extendLayer(). @Marti2203 let me know what you think

Copy link
Author

Choose a reason for hiding this comment

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

Sounds good. I will also cover the nitpick and send it tonight :)


// memmove copies data as if there was an intermediate buffer in between - so it allows for copying processes on
// overlapping src/dest ptrs if insertData is called with atIndex == m_RawDataLen, then no data is being moved.
// The data of the raw packet is still extended by dataToInsertLen
Expand Down
Loading