Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 9932] Buildbot crash output: fuzz-2014-03-27-28239.pcap

[bugzilla-daemon@xxxxxxxxxxxxx]

Evan Huus changed bug 9932

What	Removed	Added
CC		eapache@gmail.com

Comment # 1 on bug 9932 from Evan Huus

Valgrind just gives me the following, which doesn't appear possible on a simple
reading of the code...?

==2660== Invalid read of size 1
==2660==    at 0x68307B8: my_dgt_tbcd_unpack (packet-gsm_a_common.c:1965)
==2660==    by 0x6833B5A: de_bcd_num (packet-gsm_a_dtap.c:2210)
==2660==    by 0x6833CE2: de_cld_party_bcd_num (packet-gsm_a_dtap.c:2331)
==2660==    by 0x682F530: elem_lv (packet-gsm_a_common.c:1728)
==2660==    by 0x68490A1: rp_data_n_ms (packet-gsm_a_rp.c:282)
==2660==    by 0x6849387: dissect_rp (packet-gsm_a_rp.c:512)
==2660==    by 0x655E3D3: call_dissector_through_handle (packet.c:595)
==2660==    by 0x655ECC4: call_dissector_work (packet.c:682)
==2660==    by 0x65607F1: call_dissector_with_data (packet.c:2260)
==2660==    by 0x6834696: de_cp_user_data (packet-gsm_a_dtap.c:3330)
==2660==    by 0x682F530: elem_lv (packet-gsm_a_common.c:1728)
==2660==    by 0x6838C7E: dtap_sms_cp_data (packet-gsm_a_dtap.c:5465)
==2660==  Address 0x12f97040 is 0 bytes after a block of size 48 alloc'd
==2660==    at 0x4C2A420: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2660==    by 0x977B610: g_malloc (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4000.0)
==2660==    by 0x701D5AF: wmem_simple_alloc (wmem_allocator_simple.c:50)
==2660==    by 0x658CFCA: tvb_memdup (tvbuff.c:781)
==2660==    by 0x6833B34: de_bcd_num (packet-gsm_a_dtap.c:2207)
==2660==    by 0x6833CE2: de_cld_party_bcd_num (packet-gsm_a_dtap.c:2331)
==2660==    by 0x682F530: elem_lv (packet-gsm_a_common.c:1728)
==2660==    by 0x68490A1: rp_data_n_ms (packet-gsm_a_rp.c:282)
==2660==    by 0x6849387: dissect_rp (packet-gsm_a_rp.c:512)
==2660==    by 0x655E3D3: call_dissector_through_handle (packet.c:595)
==2660==    by 0x655ECC4: call_dissector_work (packet.c:682)
==2660==    by 0x65607F1: call_dissector_with_data (packet.c:2260)

But if I run it through test-captures.sh I get the following stack trace:
#0  call_dissector_work (handle=0x3030303030303030, tvb=0x3646540,
pinfo_arg=0x3611478, tree=0x3030303030303030, add_proto_name=1, data=""
    at packet.c:636
#1  0x00007f001c4ccf5a in de_rp_user_data (tvb=0x36464a0, tree=<optimized out>,
pinfo=0x3611478, offset=13, len=4, add_string=<optimized out>, 
    string_len=1024) at packet-gsm_a_rp.c:164
#2  0x00007f001c4b3531 in elem_lv (tvb=tvb@entry=0x36464a0,
tree=tree@entry=0x40f18f4, pinfo=pinfo@entry=0x3611478,
pdu_type=pdu_type@entry=2, 
    idx=idx@entry=3, offset=offset@entry=12, len=len@entry=49,
name_add=name_add@entry=0x0) at packet-gsm_a_common.c:1728
#3  0x00007f001c4cd0fa in rp_data_n_ms (tvb=0x36464a0, tree=0x40f18f4,
pinfo=0x3611478, offset=<optimized out>, len=<optimized out>)
    at packet-gsm_a_rp.c:284
#4  0x00007f001c4cd388 in dissect_rp (tvb=0x36464a0, pinfo=0x3611478,
tree=<optimized out>) at packet-gsm_a_rp.c:512
#5  0x00007f001c1e23d4 in call_dissector_through_handle
(handle=handle@entry=0x24f1bc4, tvb=tvb@entry=0x36464a0,
pinfo=pinfo@entry=0x3611478, 
    tree=tree@entry=0x358b330, data="" at packet.c:595

Based on the values of handle and tree, something is smashing the space of
globals...?

---

      You are receiving this mail because:

• You are watching all bug changes.