Wireshark · Wireshark-dev: [Wireshark-dev] Finding the bug in the unistim dissector

[Jaap Keuter <jaap.keuter@xxxxxxxxx>]

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: 15
            Display 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: 16
            Display 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