Wireshark-dev: [Wireshark-dev] Finding the bug in the unistim dissector
From: Jaap Keuter <jaap.keuter@xxxxxxxxx>
Date: Wed, 15 Aug 2007 20:32:49 +0200
Hi list,I've picked up the unistim dissector a while ago and try getting it into shape for checkin. Thing is that I'm currently running fuzztests which for the most run fine, but now I've isolated a packet that causes a segmentation fault. The problem is that I'm stuck looking for the cause.
When running Wireshark in DDD I find that the segfault occurs while priming the display filter. This is the start of the backtrace:
#0 0xb6da2a46 in fvt_cache_cb (node=0x8a86a20, data=0x0) at dfilter-macro.c:66 #1 0xb6d659d3 in proto_tree_traverse_in_order (tree=0x8a86a20, func=0xb6da2a20 <fvt_cache_cb>, data=0x0) at proto.c:478 #2 0xb6d659bf in proto_tree_traverse_in_order (tree=0x8a86ac8, func=0xb6da2a20 <fvt_cache_cb>, data=0x0) at proto.c:473 #3 0xb6d659bf in proto_tree_traverse_in_order (tree=0x8a37038, func=0xb6da2a20 <fvt_cache_cb>, data=0x0) at proto.c:473 #4 0xb6d659bf in proto_tree_traverse_in_order (tree=0x8a37398, func=0xb6da2a20 <fvt_cache_cb>, data=0x0) at proto.c:473 #5 0xb6d659bf in proto_tree_traverse_in_order (tree=0x8a373f8, func=0xb6da2a20 <fvt_cache_cb>, data=0x0) at proto.c:473 #6 0xb6d659bf in proto_tree_traverse_in_order (tree=0x8a37980, func=0xb6da2a20 <fvt_cache_cb>, data=0x0) at proto.c:473 #7 0xb6da2a0f in dfilter_macro_build_ftv_cache (tree_root=0x8a37980) at dfilter-macro.c:87
#8 0x080707e0 in cf_select_packet (cf=0x81974c0, row=0) at file.c:3256#9 0x0808db1a in packet_list_select_cb (w=0x8866010, row=0, col=-1, evt=0x0) at packet_list.c:284
which leads to --------------8<------------- static gboolean fvt_cache_cb(proto_node * node, gpointer data _U_) { field_info* finfo = node->finfo; fvt_cache_entry_t* e; if (!finfo) return FALSE;if ((e = g_hash_table_lookup(fvt_cache,finfo->hfinfo->abbrev))) --------------8<-------------
Where finfo->hfinfo proves to be 0x8. How does it get that value? When running Tshark I get most of the output: Frame 1 (124 bytes on wire, 124 bytes captured)Ethernet II, Src: Cisco_1d:c9:c0 (00:13:80:1d:c9:c0), Dst: Nortel_ff:c8:66 (00:13:65:ff:c8:66) Internet Protocol, Src: 131.253.0.203 (131.253.0.203), Dst: 10.64.50.150 (10.64.50.150) User Datagram Protocol, Src Port: commplex-main (5000), Dst Port: 22408 (22408)
UNISTIM Protocol Reliable UDP RUDP Seq Num: Normal Sequence Number (0x0000dbb4) RUDP Pkt type: Payload (2) UNISTIM Payload: Aggregate Unistim (0x01) Unistim CMD UNISTIM CMD Address: Display Manager Switch (0x17) UNISTIM CMD Length: 5 Display Cmd (switch): Clear Field (0x0f) 0001 0000 = FLAGS: For Following Byte .... ...0 = Numeric Index Field in InfoBar: False .... ..0. = Context Field in InfoBar: False .... .0.. = Date Field: False .... 0... = Time Field: False ...1 .... = Line Data: True ..0. .... = Status Bar Icon: False .0.. .... = Soft Key: False 0... .... = Soft Key Label: False 1111 1111 = FLAGS: For Following Byte .... ...1 = Line 1: True .... ..1. = Line 2: True .... .1.. = Line 3: True .... 1... = Line 4: True ...1 .... = Line 5: True ..1. .... = Line 6: True .1.. .... = Line 7: True 1... .... = Line 8: True Unistim CMD UNISTIM CMD Address: Display Manager Switch (0x17) UNISTIM CMD Length: 15Display Cmd (switch): Display Data Write address|yes control|no tag|no (0x19)
Address 0000 0100 = FLAGS: For Following Byte .... ...0 = Is Address Numberic: False .... ..0. = Context Field in the Info Bar: False .... .1.. = Write A Line: True .... 0... = Write a SoftKey: False ...0 .... = Write A Softkey Label: False 000. .... = Line Number: 0 DATA: 4. Feature Unistim CMD UNISTIM CMD Address: Display Manager Switch (0x17) UNISTIM CMD Length: 16Display Cmd (switch): Display Data Write address|yes control|no tag|no (0x19)
Address 0000 0100 = FLAGS: For Following Byte .... ...0 = Is Address Numberic: False .... ..0. = Context Field in the Info Bar: False .... .1.. = Write A Line: True .... 0... = Write a SoftKey: False ...0 .... = Write A Softkey Label: False Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1237526864 (LWP 32058)]proto_item_fill_label (fi=0x873e200, label_str=0xbfe6e4fc "...0 .... = Write A Softkey Label: False") at proto.c:3865
3865 switch(hfinfo->type) {Which, on closer examination shows that hfinfo is 0x8 as well. Why does finfo->hfinfo gets set to 0x8?? That's the question.
Thanx, Jaap
- Follow-Ups:
- Re: [Wireshark-dev] Finding the bug in the unistim dissector
- From: Luis EG Ontanon
- Re: [Wireshark-dev] Finding the bug in the unistim dissector
- Prev by Date: Re: [Wireshark-dev] [Fwd: [Wireshark-bugs] [Bug 1741] New: Privilege separation patch]
- Next by Date: [Wireshark-dev] review_for_checkin cancelled: [Bug 1741] Privilege separation patch
- Previous by thread: [Wireshark-dev] review_for_checkin cancelled: [Bug 1745] dissection of encrypted SRTP payloads and SRTCP unhelpful
- Next by thread: Re: [Wireshark-dev] Finding the bug in the unistim dissector
- Index(es):