Ethereal-dev: [Ethereal-dev] SEGV in ethereal/tethereal
Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.
From: Pierre-Yves Bonnetain <bonnetain@xxxxxxx>
Date: Sat, 26 Jan 2002 00:11:30 +0100
Hi everybody there, I've been using ethereal for some time now, and today ran into a SEGV. It seems some NULL pointer gets dereferenced somewhere. Linux 2.4.5, ethereal 0.8.20, gtk 1.2.6. Sniffing on a M$-heavy network. Here is the backtrace : (gdb) run Starting program: /tmp/ethereal-0.8.20/tethereal -r ../titi Program received signal SIGSEGV, Segmentation fault. (gdb) backtrace #0 0x0 in ?? () #1 0x8141a24 in dissect_pipe_lanman (tvb=0x836e12c, pinfo=0x82cffa0, parent_tree=0x0) at packet-smb-pipe.c:2129 #2 0x8141b93 in dissect_pipe_smb (tvb=0x836e12c, pinfo=0x82cffa0, tree=0x0) at packet-smb-pipe.c:2198 #3 0x813b122 in dissect_transact_params (pd=0x836cdd0 "", offset=114, fd=0xbffff8c8, parent=0x0, tree=0x0, si={tid = 2059, uid = 10240, mid = 42881, pid = 3399, conversation = 0x83712c0, request_val = 0x8372ad0, continuation_val = 0x0, unicode = 1, request = 0, is_interim_response = 0, parameter_count = 8, data_offset = 8, data_count = 126, ddisp = 0, trans_cmd = 0x83760f6 "LANMAN"}, max_data=190, SMB_offset=58, DataOffset=64, DataCount=126, ParameterOffset=56, ParameterCount=8, SetupAreaOffset=111, SetupCount=0, TransactName=0x8374ac0 "\\PIPE\\LANMAN") at packet-smb.c:10420 #4 0x813c413 in dissect_transact_smb (pd=0x836cdd0 "", offset=114, fd=0xbffff8c8, parent=0x0, tree=0x0, si={tid = 2059, uid = 10240, mid = 42881, pid = 3399, conversation = 0x83712c0, request_val = 0x8372ad0, continuation_val = 0x0, unicode = 1, request = 0, is_interim_response = 135897550, parameter_count = 137199768, data_offset = -1073746868, data_count = 135897476, ddisp = 0, trans_cmd = 0xbfffec54 "��6\b��,\b"}, max_data=190, SMB_offset=58) at packet-smb.c:11124 ---Type <return> to continue, or q <return> to quit--- #5 0x813ce64 in dissect_smb (tvb=0x836e0f8, pinfo=0x82cffa0, tree=0x0) at packet-smb.c:12610 #6 0x81977ca in dissector_try_heuristic (sub_dissectors=0x82d0738, tvb=0x836e0f8, pinfo=0x82cffa0, tree=0x0) at packet.c:708 #7 0x80eb0ee in dissect_netbios_payload (tvb=0x836e0f8, pinfo=0x82cffa0, tree=0x0) at packet-netbios.c:965 #8 0x80e8908 in dissect_nbss_packet (tvb=0x836e0c4, offset=4, pinfo=0x82cffa0, tree=0x0, max_data=194, is_cifs=0) at packet-nbns.c:1497 #9 0x80e8b85 in dissect_nbss (tvb=0x836e0c4, pinfo=0x82cffa0, tree=0x0) at packet-nbns.c:1672 #10 0x81971c3 in dissector_try_port (sub_dissectors=0x830d838, port=139, tvb=0x836e0c4, pinfo=0x82cffa0, tree=0x0) at packet.c:459 #11 0x814f3dd in decode_tcp_ports (tvb=0x836e090, offset=20, pinfo=0x82cffa0, tree=0x0, src_port=139, dst_port=1025) at packet-tcp.c:800 #12 0x81500ef in dissect_tcp (tvb=0x836e090, pinfo=0x82cffa0, tree=0x0) at packet-tcp.c:1101 #13 0x81971c3 in dissector_try_port (sub_dissectors=0x82d3ca8, port=6, tvb=0x836e090, pinfo=0x82cffa0, tree=0x0) at packet.c:459 #14 0x80b940c in dissect_ip (tvb=0x836e05c, pinfo=0x82cffa0, tree=0x0) at packet-ip.c:1109 #15 0x81971c3 in dissector_try_port (sub_dissectors=0x82d48c8, port=2048, tvb=0x836e05c, pinfo=0x82cffa0, tree=0x0) at packet.c:459 #16 0x8094bcb in ethertype (etype=2048, tvb=0x836e028, offset_after_etype=14, ---Type <return> to continue, or q <return> to quit--- pinfo=0x82cffa0, tree=0x0, fh_tree=0x0, etype_id=630, trailer_id=632) at packet-ethertype.c:154 #17 0x8094952 in dissect_eth (tvb=0x836e028, pinfo=0x82cffa0, tree=0x0) at packet-eth.c:256 #18 0x81971c3 in dissector_try_port (sub_dissectors=0x82d5178, port=1, tvb=0x836e028, pinfo=0x82cffa0, tree=0x0) at packet.c:459 #19 0x8096292 in dissect_frame (tvb=0x836e028, pinfo=0x82cffa0, tree=0x0) at packet-frame.c:123 #20 0x8197d9b in call_dissector (handle=0x82d51f0, tvb=0x836e028, pinfo=0x82cffa0, tree=0x0) at packet.c:909 #21 0x8196d27 in dissect_packet (p_tvb=0x836e000, pseudo_header=0x835df4c, pd=0x836cdd0 "", fd=0xbffff8c8, tree=0x0) at packet.c:210 #22 0x8195b6b in epan_dissect_new (pseudo_header=0x835df4c, data=0x836cdd0 "", fd=0xbffff8c8, tree=0x0) at epan.c:91 #23 0x8183e90 in wtap_dispatch_cb_print (user=0xbffff958 "@�+\b", phdr=0x835df38, offset=229, pseudo_header=0x835df4c, buf=0x836cdd0 "") at tethereal.c:1175 #24 0x818fbcf in wtap_loop (wth=0x835df20, count=0, callback=0x8183e0c <wtap_dispatch_cb_print>, user=0xbffff958 "@�+\b", err=0xbffff964) at wtap.c:283 #25 0x8183819 in load_cap_file (cf=0x82bfe40, out_file_type=2) at tethereal.c:927 #26 0x8182fc1 in main (argc=3, argv=0xbffffb14) at tethereal.c:585 To get things a little clearer : (gdb) up #1 0x8141a24 in dissect_pipe_lanman (tvb=0x836e12c, pinfo=0x82cffa0, parent_tree=0x0) at packet-smb-pipe.c:2129 (gdb) list 2124 if (has_ent_count) { 2125 /* 2126 * Create a protocol tree item for the 2127 * entry. 2128 */ 2129 entry_item = 2130 (*lanman->resp_data_element_item) 2131 (tvb, pinfo, data_tree, offset); 2132 entry_tree = proto_item_add_subtree( 2133 entry_item, (gdb) print *lanman $1 = {lanman_num = -1, req = 0x823477c, req_data_item = 0, ett_req_data = 0x0, req_data = 0x823477c, req_aux_data = 0x823477c, resp = 0x823477c, resp_data_item = 0, ett_resp_data = 0x0, resp_data_element_item = 0, ett_resp_data_element_item = 0x0, resp_data_list = 0x8234788, resp_aux_data = 0x823477c} It's obvious that using *lanman->resp_data_element_item will send us in no-no land :-) The data file is HUGE, but I extracted the minimum to crash properly ethereal (that's two packets). It should be attached to this message. Hope all that helps - and I would be glad (if possible, of course) to get a quick patch, in order to analyse my data ! Thanks ! -- Pierre-Yves Bonnetain Consultant S�curit� -- B&A Consultants T�l +33 (0) 563 277 241 -- Fax +33 (0) 563 277 245
Ôò¡ ÿÿ õhN<2 07 ? $ÄÏÄ E YK@ ePÀ¨?³À¨? <