Describe the bug
A heap buffer overflow with flow_decode() in the 4.3.4 version of tcpreplay
==3927793== Memcheck, a memory error detector
==3927793== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==3927793== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==3927793== Command: tcpreplay -i eth0 -q id000000,sig06,src000086,oparith16,pos16,val+6.pcap
==3927793==
==3927793== Warning: noted but unhandled ioctl 0x8994 with no size/direction hints.
==3927793== This could cause spurious value errors to appear.
==3927793== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper.
==3927793== Syscall param ioctl(HCIGETDEVLIST) points to uninitialised byte(s)
==3927793== at 0x49BB50B: ioctl (syscall-template.S:78)
==3927793== by 0x4867B41: ??? (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.9.1)
==3927793== by 0x486A614: pcap_findalldevs (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.9.1)
==3927793== by 0x11DF52: get_interface_list (interface.c:100)
==3927793== by 0x113872: tcpreplay_init (tcpreplay_api.c:119)
==3927793== by 0x112FA9: main (tcpreplay.c:67)
==3927793== Address 0x4b0ba32 is 2 bytes inside a block of size 132 alloc'd
==3927793== at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==3927793== by 0x4867B19: ??? (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.9.1)
==3927793== by 0x486A614: pcap_findalldevs (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.9.1)
==3927793== by 0x11DF52: get_interface_list (interface.c:100)
==3927793== by 0x113872: tcpreplay_init (tcpreplay_api.c:119)
==3927793== by 0x112FA9: main (tcpreplay.c:67)
==3927793==
Warning in replay.c:replay_file() line 137:
id000000,sig06,src000086,oparith16,pos16,val+6.pcap was captured using a snaplen of 5 bytes. This may mean you have truncated packets.
Warning in flows.c:flow_decode() line 227:
No Magic Number found: Juniper Ethernet (0xb2)
==3927793== Invalid read of size 2
==3927793== at 0x11EA95: flow_decode (flows.c:231)
==3927793== by 0x10F849: update_flow_stats (send_packets.c:200)
==3927793== by 0x1102E8: send_packets (send_packets.c:404)
==3927793== by 0x1174B1: replay_file (replay.c:182)
==3927793== by 0x116D3A: tcpr_replay_index (replay.c:59)
==3927793== by 0x1165A7: tcpreplay_replay (tcpreplay_api.c:1139)
==3927793== by 0x113273: main (tcpreplay.c:141)
==3927793== Address 0x4b4a6f4 is 4 bytes inside a block of size 5 alloc'd
==3927793== at 0x483DFAF: realloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==3927793== by 0x487CD77: ??? (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.9.1)
==3927793== by 0x487C488: ??? (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.9.1)
==3927793== by 0x486AF01: pcap_next (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.9.1)
==3927793== by 0x11B265: _our_safe_pcap_next (utils.c:128)
==3927793== by 0x111D06: get_next_packet (send_packets.c:919)
==3927793== by 0x110A45: send_packets (send_packets.c:360)
==3927793== by 0x1174B1: replay_file (replay.c:182)
==3927793== by 0x116D3A: tcpr_replay_index (replay.c:59)
==3927793== by 0x1165A7: tcpreplay_replay (tcpreplay_api.c:1139)
==3927793== by 0x113273: main (tcpreplay.c:141)
==3927793==
Warning in send_packets.c:send_packets() line 486:
Unable to send packet: Error with PF_PACKET send() [1]: Invalid argument (errno = 22)
==3927793==
==3927793== HEAP SUMMARY:
==3927793== in use at exit: 44,063 bytes in 5 blocks
==3927793== total heap usage: 932 allocs, 927 frees, 5,380,469 bytes allocated
==3927793==
==3927793== LEAK SUMMARY:
==3927793== definitely lost: 0 bytes in 0 blocks
==3927793== indirectly lost: 0 bytes in 0 blocks
==3927793== possibly lost: 0 bytes in 0 blocks
==3927793== still reachable: 44,063 bytes in 5 blocks
==3927793== suppressed: 0 bytes in 0 blocks
==3927793== Rerun with --leak-check=full to see details of leaked memory
==3927793==
==3927793== Use --track-origins=yes to see where uninitialised values come from
==3927793== For lists of detected and suppressed errors, rerun with: -s
==3927793== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
To Reproduce
Steps to reproduce the behavior:
download tcpreplay-4.3.4.tar.gz
cd tcpreplay-4.3.4 && ./congfigure && make && make install (+asan)
valgrind tcpreplay -i eth0 -q
Expected behavior
Exit after a failed validation
System (please complete the following information):
OS: 5.4.0-71-generic #79-Ubuntu SMP Wed Mar 24 10:56:57 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Tcpreplay Version 4.3.4
Additional context
Similar to #616. It seems fixed it get.c, but not fixed in flow.c, so #637 should be aplied to that too
Describe the bug A heap buffer overflow with flow_decode() in the 4.3.4 version of tcpreplay ==3927793== Memcheck, a memory error detector ==3927793== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==3927793== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==3927793== Command: tcpreplay -i eth0 -q id000000,sig06,src000086,oparith16,pos16,val+6.pcap ==3927793== ==3927793== Warning: noted but unhandled ioctl 0x8994 with no size/direction hints. ==3927793== This could cause spurious value errors to appear. ==3927793== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. ==3927793== Syscall param ioctl(HCIGETDEVLIST) points to uninitialised byte(s) ==3927793== at 0x49BB50B: ioctl (syscall-template.S:78) ==3927793== by 0x4867B41: ??? (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.9.1) ==3927793== by 0x486A614: pcap_findalldevs (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.9.1) ==3927793== by 0x11DF52: get_interface_list (interface.c:100) ==3927793== by 0x113872: tcpreplay_init (tcpreplay_api.c:119) ==3927793== by 0x112FA9: main (tcpreplay.c:67) ==3927793== Address 0x4b0ba32 is 2 bytes inside a block of size 132 alloc'd ==3927793== at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==3927793== by 0x4867B19: ??? (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.9.1) ==3927793== by 0x486A614: pcap_findalldevs (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.9.1) ==3927793== by 0x11DF52: get_interface_list (interface.c:100) ==3927793== by 0x113872: tcpreplay_init (tcpreplay_api.c:119) ==3927793== by 0x112FA9: main (tcpreplay.c:67) ==3927793== Warning in replay.c:replay_file() line 137: id000000,sig06,src000086,oparith16,pos16,val+6.pcap was captured using a snaplen of 5 bytes. This may mean you have truncated packets. Warning in flows.c:flow_decode() line 227: No Magic Number found: Juniper Ethernet (0xb2) ==3927793== Invalid read of size 2 ==3927793== at 0x11EA95: flow_decode (flows.c:231) ==3927793== by 0x10F849: update_flow_stats (send_packets.c:200) ==3927793== by 0x1102E8: send_packets (send_packets.c:404) ==3927793== by 0x1174B1: replay_file (replay.c:182) ==3927793== by 0x116D3A: tcpr_replay_index (replay.c:59) ==3927793== by 0x1165A7: tcpreplay_replay (tcpreplay_api.c:1139) ==3927793== by 0x113273: main (tcpreplay.c:141) ==3927793== Address 0x4b4a6f4 is 4 bytes inside a block of size 5 alloc'd ==3927793== at 0x483DFAF: realloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==3927793== by 0x487CD77: ??? (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.9.1) ==3927793== by 0x487C488: ??? (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.9.1) ==3927793== by 0x486AF01: pcap_next (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.9.1) ==3927793== by 0x11B265: _our_safe_pcap_next (utils.c:128) ==3927793== by 0x111D06: get_next_packet (send_packets.c:919) ==3927793== by 0x110A45: send_packets (send_packets.c:360) ==3927793== by 0x1174B1: replay_file (replay.c:182) ==3927793== by 0x116D3A: tcpr_replay_index (replay.c:59) ==3927793== by 0x1165A7: tcpreplay_replay (tcpreplay_api.c:1139) ==3927793== by 0x113273: main (tcpreplay.c:141) ==3927793== Warning in send_packets.c:send_packets() line 486: Unable to send packet: Error with PF_PACKET send() [1]: Invalid argument (errno = 22) ==3927793== ==3927793== HEAP SUMMARY: ==3927793== in use at exit: 44,063 bytes in 5 blocks ==3927793== total heap usage: 932 allocs, 927 frees, 5,380,469 bytes allocated ==3927793== ==3927793== LEAK SUMMARY: ==3927793== definitely lost: 0 bytes in 0 blocks ==3927793== indirectly lost: 0 bytes in 0 blocks ==3927793== possibly lost: 0 bytes in 0 blocks ==3927793== still reachable: 44,063 bytes in 5 blocks ==3927793== suppressed: 0 bytes in 0 blocks ==3927793== Rerun with --leak-check=full to see details of leaked memory ==3927793== ==3927793== Use --track-origins=yes to see where uninitialised values come from ==3927793== For lists of detected and suppressed errors, rerun with: -s ==3927793== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
To Reproduce Steps to reproduce the behavior:
Expected behavior Exit after a failed validation
System (please complete the following information):
Additional context Similar to #616. It seems fixed it get.c, but not fixed in flow.c, so #637 should be aplied to that too