Fix use-of-uninitialized-value in PcapNgFileReaderDevice::getNextPacketInternal

[Shubham7-1]

Summary

Fixes the MSAN-reported Use-of-uninitialized-value in pcpp::PcapNgFileReaderDevice::getNextPacketInternal (OSS-Fuzz issue, crash type reported in FuzzWriterNg).

issue: https://issues.oss-fuzz.com/issues/479882050

Root Cause

In light_get_next_packet (light_pcapng_ext.c), the LIGHT_SIMPLE_PACKET_BLOCK branch sets packet_header->data_link only when interface_block_count > 0:

if (pcapng->file_info->interface_block_count > 0)
    packet_header->data_link = pcapng->file_info->link_types[0];
// else: data_link left UNINITIALIZED

When a pcapng file contains a Simple Packet Block without any preceding Interface Description Block, data_link is never written. Back in getNextPacketInternal, the uninitialized pktHeader.data_link value is then read by m_BpfWrapper.matches() and RawPacket::setRawData(), triggering MSAN.

Changes

3rdParty/LightPcapNg/LightPcapNg/src/light_pcapng_ext.c

Added an else clause in the SPB path of light_get_next_packet to always assign data_link. Uses the same 0xFFFF sentinel already used in the EPB "out-of-range interface_id" case, meaning unknown/invalid link type.

Pcap++/src/PcapFileDevice.cpp

Zero-initialized light_packet_header pktHeader{} in getNextPacketInternal as defense-in-depth, ensuring no field is ever read uninitialized regardless of which code path light_get_next_packet takes.