Date: Tue, 7 Sep 2004 11:14:30 +0200 (CEST) From: Matthias Andree <matthias.andree@web.de> To: FreeBSD-gnats-submit@FreeBSD.org Cc: re@FreeBSD.org Subject: bin/71453: tcpdump segfaults on PPP IPV6CP traffic Message-ID: <20040907091430.47CD81B20D@merlin.emma.line.org> Resent-Message-ID: <200409070920.i879KOOj082297@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 71453 >Category: bin >Synopsis: tcpdump segfaults on PPP IPV6CP traffic >Confidential: no >Severity: critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Sep 07 09:20:24 GMT 2004 >Closed-Date: >Last-Modified: >Originator: Matthias Andree >Release: FreeBSD 5.3-BETA3 i386 >Organization: >Environment: System: FreeBSD merlin.emma.line.org 5.3-BETA3 FreeBSD 5.3-BETA3 #7: Mon Sep 6 12:28:24 CEST 2004 toor@merlin.emma.line.org:/usr/src/sys/i386/compile/MA5 i386 >Description: tcpdump aborts with a SIGSEGV when it sees PPP IPv6CP traffic. The "crash" portion of this bug has apparently been fixed in tcpdump.org's CVS as of July 13th, 2004, but it appears the upstream tcpdump still has no IPv6CP support. Relevant excerpt from post-mortem stacktrace: GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. ... This GDB was configured as "i386-marcel-freebsd"... Core was generated by `tcpdump'. Program terminated with signal 11, Segmentation fault. ... #0 0x00000000 in ?? () (gdb) bt full #0 0x00000000 in ?? () No symbol table info available. #1 0x0807022c in handle_ctrl_proto (proto=32855, pptr=0x81892b0 "\001\001", length=14) at /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ppp.c:447 typestr = 0x80cb8e0 "unknown" code = 10 len = 14 pfunc = (int (*)(const u_char *, int)) 0 x = 10 j = 0 tptr = ( const u_char *) 0x81892b4 "\001\n\002`\227ÿþ¼ÅôV(Üv=AÅ\222\016" #2 0x08071587 in handle_ppp (proto=0, p=0x81892b0 "\001\001", length=14) at /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ppp.c:1064 No locals. #3 0x08071740 in ppp_print (p=0x81892b0 "\001\001", length=14) at /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ppp.c:1146 proto = 32855 olen = 16 hdr_len = 2 #4 0x08071c8d in pppoe_print (bp=0x81892a8 "\021", length=22) at /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-pppoe.c:212 pppoe_ver = 37556 pppoe_type = 1 pppoe_code = 0 pppoe_sessionid = 696 pppoe_length = 16 pppoe_packet = (const u_char *) 0xe <Address 0xe out of bounds> pppoe_payload = (const u_char *) 0x81892ae "\200W\001\001" >How-To-Repeat: 1. Configure a PPPoE link via a certain interface, say xl1 but do not yet run ppp 2. Attach tcpdump -vns2000 -ixl1 (use the same interface for -i as in #1) 3. run ppp to start this link tcpdump crashes as ppp tries to negotiate IPv6. >Fix: 1. tcpdump acts outright stupid in print-ppp.c ll. 425ff by setting pfunc=NULL and then dereferencing it in a function call. Please consider importing http://cvs.tcpdump.org/cgi-bin/cvsweb/tcpdump/print-ppp.c?r1=1.89.2.3&r2=1.89.2.4 2. add a proper print_ipv6cp_config_options function (upstream issue) >Release-Note: >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040907091430.47CD81B20D>