Fix https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=61820

[sashashura]

The root cause was that assign was called with a pointer close the end of buffer, so accessing TLVRawData to retrieve recordLen as already reading past the end of the buffer.

The main fix is in TLVData.h and NflogLayer.h, but I had to change the signature of assign and constructors.

[codecov]

Codecov Report

Attention: 6 lines in your changes are missing coverage. Please review.

Comparison is base (9fbc712) 82.70% compared to head (35c740e) 82.72%.
Report is 3 commits behind head on dev.

Files	Patch %	Lines
Packet++/header/IPv4Layer.h	88.88%	2 Missing ⚠️
Packet++/header/IPv6Extensions.h	81.81%	2 Missing ⚠️
Packet++/header/DhcpLayer.h	90.90%	1 Missing ⚠️
Packet++/header/TcpLayer.h	90.90%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##              dev    #1234      +/-   ##
==========================================
+ Coverage   82.70%   82.72%   +0.01%     
==========================================
  Files         159      159              
  Lines       20329    20394      +65     
  Branches     7687     7707      +20     
==========================================
+ Hits        16814    16870      +56     
- Misses       2893     2902       +9     
  Partials      622      622              

Flag	Coverage Δ
alpine317	72.33% <44.00%> (+<0.01%)	⬆️
centos7	74.42% <48.27%> (-0.06%)	⬇️
fedora37	72.33% <44.00%> (+0.05%)	⬆️
macos-11	61.28% <73.84%> (-0.04%)	⬇️
macos-12	61.34% <73.84%> (-0.04%)	⬇️
macos-ventura	61.32% <73.84%> (-0.04%)	⬇️
mingw32	70.14% <40.00%> (-0.11%)	⬇️
mingw64	70.21% <40.00%> (-0.06%)	⬇️
npcap	83.24% <90.76%> (-0.04%)	⬇️
ubuntu1804	74.88% <50.00%> (-0.06%)	⬇️
ubuntu2004	73.10% <44.00%> (-0.01%)	⬇️
ubuntu2204	72.17% <44.00%> (+<0.01%)	⬆️
ubuntu2204-icpx	59.27% <70.76%> (+0.04%)	⬆️
unittest	82.72% <91.89%> (+0.01%)	⬆️
windows-2019	83.28% <90.76%> (-0.01%)	⬇️
windows-2022	83.28% <90.76%> (-0.03%)	⬇️
winpcap	83.25% <90.76%> (-0.01%)	⬇️
xdp	∅ <ø> (∅)
zstd	73.67% <76.92%> (-0.09%)	⬇️

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.

[sashashura]

@seladb, too big?

[seladb]

@seladb, too big?

Yes, it'll take me some time to review. Sorry for the delay. Is it possible to make the PR smaller?

[sashashura]

I have already put everything that can be considered unrelated into separate commits in the pr. Extracting it to 4 different prs doesn't make much sense.
The second commit is to make it build - it is not the first deprecated function in the project, but all of sudden it started giving warnings for the deprecated functions and they are treated as errors.
Another interesting glitch that it error-ed on two more warnings. I think that was the intention from the very beginning in PcapPlusPlus to treat warnings as errors, but I wonder what I have changed that it triggered it. Anyway, 3rd and 4th commits are really small and fix two separate warnings.

[seladb]

@sashashura if I understand correctly the main issue is in getFirstTLVRecord() and getNextTLVRecord(). Maybe a simpler fix that won't involve deprecating so many methods can be something like this:

Add bool TLVRecord::canAssign(uint8_t* recordRawData, size_t tlvDataLen) that will do these checks. If it returns false we call assign(nullptr), otherwise we call assign(tlvDataBasePtr). This method will be used in getFirstTLVRecord()andgetNextTLVRecord()`. Will that be sufficient to solve the issue?

[seladb]

Why are the changes in this file needed?

[sashashura]

As I wrote previously The second commit is to make it build - it is not the first deprecated function in the project, but all of sudden it started giving warnings for the deprecated functions and they are treated as errors.
Since now I do not deprecate anything, the changes are not needed, I have reverted it.