https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278034
Bug ID: 278034
Summary: tcpdump's ip6_print can read beyond buffer end
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: bin
Assignee: [email protected]
Reporter: [email protected]
Created attachment 249560
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=249560&action=edit
a packet trace file that causes tcpdump to read beyond the end of a buffer in
pfsync_print()
tcpdump's ip6_print() is passed the real length of the packet buffer
in the length argument. It pulls len from the packet header:
payload_len = GET_BE_U_2(ip6->ip6_plen);
if (payload_len != 0) {
len = payload_len + sizeof(struct ip6_hdr);
if (length < len)
ND_PRINT("truncated-ip6 - %u bytes missing!",
len - length);
If the header's claimed length is greater than the buffer size,
tcpdump prints a warning but then continues.
Later len (rather than length) is passed to ip_demux_print():
ip_demux_print(ndo, cp, len, 6, fragmented,
GET_U_1(ip6->ip6_hlim), nh, bp);
and is used by some of the functions it calls as the buffer length.
For example, pfsync_print() uses this len as the limit for how far
it looks into the buffer:
while (plen > 0) {
if (len < sizeof(*subh))
break;
...;
len -= sizeof(*subh);
Since this len was pulled from the packet, a broken packet can cause a
read overrun.
I've attached a demo packet that causes pfsync_print() to read past
the end of the buffer. You may need an address sanitizer or
valgrind to see the problem.
# uname -a
FreeBSD stock14 15.0-CURRENT FreeBSD 15.0-CURRENT #20
main-n268970-619e6f1f9288: Sat Mar 23 16:25:40 AST 2024
root@stock14:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
# tcpdump --version
tcpdump version 4.99.4
libpcap version 1.10.4
OpenSSL 3.0.13 30 Jan 2024
# valgrind tcpdump -v -v -n -r - -K < tcpdump43a.dat
..
==9292== Invalid read of size 2
==9292== at 0x22C90E: pfsync_print (src/contrib/tcpdump/print-pfsync.c:168)
==9292== by 0x1C40EE: ip6_print (src/contrib/tcpdump/print-ip6.c:487)
==9292== by 0x1B56BD: ethertype_print
(src/contrib/tcpdump/print-ether.c:628)
==9292== by 0x1B5121: ether_common_print
(src/contrib/tcpdump/print-ether.c:391)
==9292== by 0x1B5213: ether_print (src/contrib/tcpdump/print-ether.c:448)
==9292== by 0x1B5213: ether_if_print (src/contrib/tcpdump/print-ether.c:464)
==9292== by 0x18C30E: pretty_print_packet (src/contrib/tcpdump/print.c:417)
==9292== by 0x225D00: print_packet (src/contrib/tcpdump/tcpdump.c:3139)
==9292== by 0x48ACC9D: pcap_offline_read (in /lib/libpcap.so.8)
==9292== by 0x48AB248: pcap_loop (in /lib/libpcap.so.8)
==9292== by 0x2240AC: main (src/contrib/tcpdump/tcpdump.c:2581)
==9292== Address 0x5a3ce90 is 0 bytes after a block of size 1,024 alloc'd
==9292== at 0x484CDB4: malloc (vg_replace_malloc.c:446)
==9292== by 0x48AF550: pcap_check_header (in /lib/libpcap.so.8)
==9292== by 0x48AC9E2: pcap_fopen_offline_with_tstamp_precision (in
/lib/libpcap.so.8)
==9292== by 0x48AC8DD: pcap_open_offline_with_tstamp_precision (in
/lib/libpcap.so.8)
==9292== by 0x2235EF: main (src/contrib/tcpdump/tcpdump.c:2079)
--
You are receiving this mail because:
You are the assignee for the bug.
