Fix use-of-uninitialized-value in PcapNgFileReaderDevice::getNextPacketInternal#2132
Fix use-of-uninitialized-value in PcapNgFileReaderDevice::getNextPacketInternal#2132Shubham7-1 wants to merge 5 commits into
Conversation
…etInternal - Zero-initialize light_packet_header pktHeader in getNextPacketInternal to prevent MSAN use-of-uninitialized-value on any path where light_get_next_packet does not fill every field. - Fix light_get_next_packet's LIGHT_SIMPLE_PACKET_BLOCK branch: add an else clause so packet_header->data_link is always set (to 0xFFFF) when there are no interface blocks, eliminating the root cause of the uninitialized read. Agent-Logs-Url: https://github.com/Shivam7-1/PcapPlusPlus/sessions/40af4014-b148-45f0-8e4f-9f159064c5d1 Co-authored-by: Shivam7-1 <55046031+Shivam7-1@users.noreply.github.com>
Agent-Logs-Url: https://github.com/Shivam7-1/PcapPlusPlus/sessions/40af4014-b148-45f0-8e4f-9f159064c5d1 Co-authored-by: Shivam7-1 <55046031+Shivam7-1@users.noreply.github.com>
…-value Fix use-of-uninitialized-value in PcapNgFileReaderDevice::getNextPacketInternal
Fix use-of-uninitialized-value in PcapNgFileReaderDevice::getNextPacketInternal
seladb
left a comment
seladb
left a comment
There was a problem hiding this comment.
@Shubham7-1 we can add the example file in https://issues.oss-fuzz.com/issues/479882050 to here: https://github.com/Shubham7-1/PcapPlusPlus/tree/685e23905e4c319ba693f21a69846442ec540be1/Tests/Fuzzers/RegressionTests/regression_samples
These are regression files that we run in CI.
|
@seladb Thanks For your Review
I think its not possible |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## dev #2132 +/- ##
==========================================
- Coverage 82.66% 82.65% -0.01%
==========================================
Files 332 332
Lines 59706 59700 -6
Branches 12384 12592 +208
==========================================
- Hits 49353 49348 -5
- Misses 8952 8965 +13
+ Partials 1401 1387 -14
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
hii @seladb team any update ? |
@Shivam7-1 why is it not possible? 🤔 |
@Shubham7-1 did you see my previous message? ☝️ |
Summary
Fixes the MSAN-reported
Use-of-uninitialized-valueinpcpp::PcapNgFileReaderDevice::getNextPacketInternal(OSS-Fuzz issue, crash type reported inFuzzWriterNg).issue: https://issues.oss-fuzz.com/issues/479882050
Root Cause
In
light_get_next_packet(light_pcapng_ext.c), theLIGHT_SIMPLE_PACKET_BLOCKbranch setspacket_header->data_linkonly wheninterface_block_count > 0:When a pcapng file contains a Simple Packet Block without any preceding Interface Description Block,
data_linkis never written. Back ingetNextPacketInternal, the uninitializedpktHeader.data_linkvalue is then read bym_BpfWrapper.matches()andRawPacket::setRawData(), triggering MSAN.Changes
3rdParty/LightPcapNg/LightPcapNg/src/light_pcapng_ext.cAdded an
elseclause in the SPB path oflight_get_next_packetto always assigndata_link. Uses the same0xFFFFsentinel already used in the EPB "out-of-range interface_id" case, meaning unknown/invalid link type.Pcap++/src/PcapFileDevice.cppZero-initialized
light_packet_header pktHeader{}ingetNextPacketInternalas defense-in-depth, ensuring no field is ever read uninitialized regardless of which code pathlight_get_next_packettakes.