Wireshark-bugs: [Wireshark-bugs] [Bug 9078] Buildbot crash output: fuzz-2013-08-26-30972.pcap
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Fri, 30 Aug 2013 01:47:41 +0000

changed bug 9078

What Removed Added
CC   eapache@gmail.com

Comment # 1 on bug 9078 from 
Relevant stack trace snip:
#5  0x00007fe4cdbe05c1 in wmem_tree_lookup32_array_helper (tree=0x32eedc0,
key=<optimized out>, helper=<optimized out>) at wmem_tree.c:594
#6  0x00007fe4cdbe061c in wmem_tree_lookup32_array (tree=<optimized out>,
key=<optimized out>) at wmem_tree.c:621
#7  0x00007fe4cdbe0664 in wmem_tree_lookup_string (tree=0x32eedc0,
k=k@entry=0x1d67680 "s81lE-", '\252' <repeats 194 times>...,
flags=flags@entry=1)
    at wmem_tree.c:543
#8  0x00007fe4cd875c2f in xmpp_iq_reqresp_track
(pinfo=pinfo@entry=0x7fff8da61a88, packet=packet@entry=0x333fa40,
xmpp_info=xmpp_info@entry=0x32e7ce0)
    at packet-xmpp-utils.c:60
#9  0x00007fe4cd876cf2 in dissect_xmpp (tvb=0x32f86d0, pinfo=0x7fff8da61a88,
tree=<optimized out>) at packet-xmpp.c:498
#10 0x00007fe4cd1852b4 in call_dissector_through_handle
(handle=handle@entry=0x2e5cb40, tvb=tvb@entry=0x32f86d0,
pinfo=pinfo@entry=0x7fff8da61a88, 
    tree=tree@entry=0x330b960, data="" at packet.c:492

Frame 509.

The assertion was copied from the emem tree and has been in-place forever
(before XML was switched to wmem, in other words).

It looks like malformed XML is causing the dissector to try and use a long
string (~1400 bytes) as a key, which ends up being longer than the max key the
tree will deal with.

I'm not sure this is really a bug, and I'm tempted to remove the assertion. In
this case it seems that the dissector is doing the right thing, and the tree
should just handle a key that long...

Thoughts anyone?

You are receiving this mail because:
  • You are watching all bug changes.