Evan Huus
changed
bug 9078
Comment # 1
on bug 9078
from Evan Huus
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.