Fix: Linux SLL/SLL2 Panic on Oversized Addresses

Summary

Fixed a panic in LinuxSLL and LinuxSLL2 layers that occurred when processing packets with hardware addresses exceeding MaxEndpointSize (16 bytes).

Problem

The LinkFlow() method in both LinuxSLL and LinuxSLL2 layers was passing the raw hardware address directly to gopacket.NewFlow() without validating its length. When a packet contained an address larger than MaxEndpointSize (16 bytes), this caused a panic:

panic: flow raw byte length greater than MaxEndpointSize

Root Cause

1. Linux SLL packets can have variable-length hardware addresses (up to 8 bytes according to spec)
2. Malformed or unusual packets may claim larger address sizes
3. gopacket.NewFlow() uses fixed-size byte arrays for performance and requires addresses ≤ 16 bytes
4. The code didn't validate address length before creating flows, causing panics on oversized addresses

Reproduction

A test pcap file that reproduces this issue is included:

• Location: layers/testdata/linux_sll_oversized_addr.pcapng

Stack Trace (Anonymized)

panic: flow raw byte length greater than MaxEndpointSize

goroutine 126014445 [running]:
github.com/gopacket/gopacket.NewFlow(...)
	/Users/xxx/go/pkg/mod/github.com/gopacket/gopacket@v1.4.0/flows.go:218
github.com/gopacket/gopacket/layers.(*LinuxSLL).LinkFlow(0x14013bc5f68?)
	/Users/xxx/go/pkg/mod/github.com/gopacket/gopacket@v1.4.0/layers/linux_sll.go:68 +0xd4
github.com/dreadl0ck/netcap/decoder/utils.NewPacketInfo({0x103b3ed60, 0x140017c6580})
	/Users/xxx/go/src/github.com/dreadl0ck/netcap/decoder/utils/packet_info.go:38 +0xb8
github.com/dreadl0ck/netcap/decoder/packet.init.func45({0x103b3ed60?, 0x140017c6580?})
	/Users/xxx/go/src/github.com/dreadl0ck/netcap/decoder/packet/device_profile.go:214 +0x24
github.com/dreadl0ck/netcap/decoder/packet.(*Decoder).Decode(0x14000ae6150, {0x103b3ed60?, 0x140017c6580?})
	/Users/xxx/go/src/github.com/dreadl0ck/netcap/decoder/packet/packet_decoder.go:305 +0x48
github.com/dreadl0ck/netcap/collector.(*Collector).worker.func1()
	/Users/xxx/go/src/github.com/dreadl0ck/netcap/collector/worker.go:165 +0xe18
created by github.com/dreadl0ck/netcap/collector.(*Collector).worker in goroutine 1
	/Users/xxx/go/src/github.com/dreadl0ck/netcap/collector/worker.go:50 +0x1ac

Solution

Modified LinkFlow() methods in both layers to truncate oversized addresses to MaxEndpointSize before creating flows. This approach:

• Gracefully handles malformed packets instead of crashing
• Maintains backward compatibility - no API changes
• Preserves performance - no allocations, just a length check
• Allows processing to continue - problematic packets are handled, not rejected

Changes

File: layers/linux_sll.go

func (sll *LinuxSLL) LinkFlow() gopacket.Flow {
	// Truncate address to MaxEndpointSize to prevent panics
	// Linux SLL addresses should normally be 6-8 bytes, but malformed
	// packets may claim larger sizes. This gracefully handles such cases
	// by truncating oversized addresses instead of panicking.
	addr := sll.Addr
	if len(addr) > gopacket.MaxEndpointSize {
		addr = addr[:gopacket.MaxEndpointSize]
	}
	return gopacket.NewFlow(EndpointMAC, addr, nil)
}

File: layers/linux_sll2.go

func (sll *LinuxSLL2) LinkFlow() gopacket.Flow {
	// Truncate address to MaxEndpointSize to prevent panics
	// Linux SLL2 addresses should normally be 6-8 bytes, but malformed
	// packets may claim larger sizes. This gracefully handles such cases
	// by truncating oversized addresses instead of panicking.
	addr := sll.Addr
	if len(addr) > gopacket.MaxEndpointSize {
		addr = addr[:gopacket.MaxEndpointSize]
	}
	return gopacket.NewFlow(EndpointMAC, addr, nil)
}

Testing

To verify the fix:

go test -v ./layers -run 'TestLinuxSLL.*Truncation'

Verify no panics occur and processing completes successfully

Impact

• Before: Applications panic and crash when encountering oversized Linux SLL addresses
• After: Applications handle oversized addresses gracefully by truncating them
• Side effect: Flow hashing for packets with addresses >16 bytes will use truncated addresses