4.5.5: fix heap over-read in get_layer4_v6

[fklassen]

Follow-up to #1067. Adds one more security fix to the 4.5.5 release, and v4.5.5 has been re-tagged to include it (the GitHub release was still an unpublished draft with no assets attached, so the tag had no consumers).

GHSA-jj65-mrgg-f5fx — heap buffer over-read in get_layer4_v6()

Reported by msxfXF in 2024 against 4.4.4 and marked patched, but it was never actually fixed — the reporter's proof-of-concept still reproduced on 4.5.4 and on the original 4.5.5 tag:

ERROR: AddressSanitizer: heap-buffer-overflow
READ of size 1
    #0 in get_layer4_v6  src/common/get.c:670

get_ipv6_next() validates the header it is given, but the pointer it returns is only checked with ptr > end_ptr — so it may be exactly end_ptr, or leave fewer bytes than a tcpr_ipv6_ext_hdr_base needs. get_layer4_v6() then read ip_nh straight off that pointer, one byte past the packet buffer, for a crafted IPv6 packet whose extension-header chain runs to the end of the captured data.

Reachable from tcpprep, tcprewrite and tcpreplay when reading an untrusted pcap.

Adds ipv6_exthdr_fits() and applies it at the three sites that dereference such a pointer: both extension-header cases reading exthdr->ip_nh, and the default case reading next->ip_len. The fragment case previously checked (u_char *)exthdr > end_ptr, which permits exthdr == end_ptr and so did not prevent the read.

get_ipv6_next() itself is unchanged: its ptr > end_ptr checks are correct for callers that only use the result as an opaque layer-4 pointer, and tightening them would reject valid zero-length payloads.

Verification

ASan build against the reporter's PoC: clean for both tcpprep --port and tcprewrite, where an unmodified 4.5.4 still aborts. The tcpprep (20) and tcprewrite (36) test groups pass, and the six fragroute proof-of-concept rules files from #1067 stay clean.

Also on 4.6.0-beta2 as 9d291ec.

Reported by msxfXF.

🤖 Generated with Claude Code

https://claude.ai/code/session_01W2Rdq79uuiVVq9G9GyuvDw