asn2wrs allowed a Buildbot crash output: fuzz-2011-10-25-30900.pcap

This issue was migrated from bug 6485 in our old bug tracker.

Original bug information:

Reporter: Buildbot Builder
Status: RESOLVED FIXED
Product: Wireshark
Component: Dissection engine (libwireshark)
OS: Ubuntu
Platform: x86-64
Version: unspecified

Buildbot Builder said:

Build Information:

Problems have been found with the following capture file:

http://www.wireshark.org/download/automated/captures/fuzz-2011-10-25-30900.pcap

stderr:

** (process:20212): WARNING **: giop:Invalid v_minor value = 245

[ no debug trace ]

added libwireshark osubuntu labels

Jeff Morriss said:

*** Bug #6491 (closed) has been marked as a duplicate of this bug. ***

Jeff Morriss said:

(gdb) bt
#0  0x00000031a2255ec0 in g_slice_free_chain_with_offset () from /lib64/libglib-2.0.so.0
#1  0x00007f5b4df8afb1 in frame_data_cleanup (fdata=0x7fffd2e10d90) at ../../epan/frame_data.c:296
#2  0x0000000000424e99 in process_packet (cf=<value optimized out>, offset=<value optimized out>,
    whdr=<value optimized out>, pseudo_header=0x3615b10, pd=0x1 <Address 0x1 out of bounds>,
    filtering_tap_listeners=<value optimized out>, tap_flags=<value optimized out>) at ../tshark.c:3024
#3  0x0000000000427aaf in load_cap_file (max_packet_count=0) at ../tshark.c:2788
#4  main (argc=<value optimized out>, argv=<value optimized out>) at ../tshark.c:1744
(gdb) print *fdata
No symbol "fdata" in current context.
(gdb) up
#1  0x00007f5b4df8afb1 in frame_data_cleanup (fdata=0x7fffd2e10d90) at ../../epan/frame_data.c:296
296	    g_slist_free(fdata->pfd);
(gdb) print *fdata
$1 = {
  pfd = 0xffffffff,
  num = 1,
  pkt_len = 106,
  cap_len = 106,
  cum_bytes = 106,
  file_off = 48,


Not sure how fdata->pfd is getting set to -1.

Jeff Morriss said:

*** Bug #6493 (closed) has been marked as a duplicate of this bug. ***

Jeff Morriss said:

6493 provides a different bt but appears to have the same root cause:

#0  0x00000031a225659b in g_slist_find_custom () from /lib64/libglib-2.0.so.0
#1  0x00007f1a79039472 in p_get_proto_data (fd=<value optimized out>, proto=<value optimized out>)
    at ../../epan/frame_data.c:86
#2  0x00007f1a795e45af in dissect_tcp (tvb=0x35df8c0, pinfo=0x7fffdf2e4990, tree=0x7f1a77dcb000)
    at ../../../epan/dissectors/packet-tcp.c:3840
#3  0x00007f1a7903d821 in call_dissector_through_handle (handle=0x2c05fd0, tvb=0x35df8c0,
    pinfo=0x7fffdf2e4990, tree=0x7f1a77dcb000) at ../../epan/packet.c:386
#4  0x00007f1a7903df80 in call_dissector_work (handle=0x2c05fd0, tvb=0x35df8c0,
    pinfo_arg=0x7fffdf2e4990, tree=0x7f1a77dcb000, add_proto_name=1) at ../../epan/packet.c:477
#5  0x00007f1a7903efb2 in dissector_try_uint_new (sub_dissectors=<value optimized out>, uint_val=6,
    tvb=0x35df8c0, pinfo=0x7fffdf2e4990, tree=0x7f1a77dcb000, add_proto_name=1)
    at ../../epan/packet.c:902

(gdb) print *pinfo->fd
$3 = {
  pfd = 0xffffffff,
  num = 1,
  pkt_len = 122,
  cap_len = 122,

Jeff Morriss said:

*** Bug #6494 (closed) has been marked as a duplicate of this bug. ***

Jeff Morriss said:

*** Bug #6495 (closed) has been marked as a duplicate of this bug. ***

Jeff Morriss said:

Oh good grief.  Looks like my tshark was not properly (re)built. Ignore all my previous comments.  The backtrace actually looks like:

#0  0x00000031a0a32f05 in raise () from /lib64/libc.so.6
#1  0x00000031a0a34a73 in abort () from /lib64/libc.so.6
#2  0x00007fa2c22ff226 in proto_item_add_subtree (pi=<value optimized out>,
    idx=<value optimized out>) at ../../epan/proto.c:4223
#3  0x00007fa2c2782652 in dissect_attribute_value_pairs (offset=180)
    at ../../../epan/dissectors/packet-radius.c:987
#4  dissect_radius (tvb=0x3f39640, pinfo=0x7fffbe668b10,
    tree=<value optimized out>)
    at ../../../epan/dissectors/packet-radius.c:1626
#5  0x00007fa2c22f3b3c in call_dissector_through_handle (handle=0x2b719a0,
    tvb=0x3f39640, pinfo=0x7fffbe668b10, tree=0x7fa2c1081000)
    at ../../epan/packet.c:382

Jeff Morriss said:

Oh good grief.  Ignore the backtrace in comment 7, too. That's caused by me using an out-of-tree build and bug 5664 (so my tshark wasn't picking up the radius files which eventually causes a DISSECTOR_ASSERT).

The REAL problem is that the GSM_MAP dissector is using this value_string_ext in the hf without BASE_EXT_STRING:

    { &hf_gsm_old_localValue,
      { "localValue", "gsm_old.localValue",
        FT_INT32, BASE_DEC, &gsm_old_GSMMAPOperationLocalvalue_vals_ext, 0,
        "OperationLocalvalue", HFILL }},

This, in turn, appears to be caused because OperationLocalValue is an alias for/of GSMMAPOperationLocalValue and only the latter is defined with .USE_VALS_EXT.

I can fix it by doing:

Index: asn1/gsm_map/gsm_map.cnf
===================================================================
--- asn1/gsm_map/gsm_map.cnf	(revision 39628)
+++ asn1/gsm_map/gsm_map.cnf	(working copy)
@@ -54,6 +54,7 @@

 #.USE_VALS_EXT
 GSMMAPOperationLocalvalue
+OperationLocalvalue

 #.EXPORTS
 AddressString


But it seems to be that asn2wrs should arguably be figuring this out on its own.

Can someone knowledgeable in asn2wrs take a look?

Jeff Morriss said:

*** Bug #6622 (closed) has been marked as a duplicate of this bug. ***

Jeff Morriss said:

Anders checked in the temporary fix in r40033. But it would still be best to fix asn2wrs to do this automagically, so leaving this bug open.

Jeff Morriss said:

Update the summary and Importance to indicate the crash has been fixed, this is just waiting for a asn2wrs fix.

Michael Mann said:

Just regenerated the GSM_MAP and the EXT_BASE_STRING is included with hf_gsm_old_localValue, so I'm guessing asn2wrs was fixed along the way.

closed

mentioned in issue #6491 (closed)

mentioned in issue #6493 (closed)

mentioned in issue #6494 (closed)

mentioned in issue #6495 (closed)

mentioned in issue #6622 (closed)