Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 10635] Buildbot crash output: fuzz-2014-10-26-32183.pcap

[bugzilla-daemon@xxxxxxxxxxxxx]

Comment # 3 on bug 10635 from Martin Kaiser

this is what happens:

out_buf = g_malloc(...)
proto_tree_add_text(udvm_tree, bytcode_tvb, 0, -1, "some err msg");
g_free(...)

bytecode_tvb has 0 length and proto_tree_add_text() throws an exception

#0  except_throw (group=group@entry=1, code=code@entry=2, msg=0x0) at
except.c:275
#1  0x00007ffff497fe07 in tvb_ensure_captured_length_remaining
(tvb=tvb@entry=0xf6a140, offset=offset@entry=0) at tvbuff.c:480
#2  0x00007ffff495c947 in get_hfi_length (tvb=tvb@entry=0xf6a140,
start=start@entry=0, length=length@entry=0x7fffffffcafc,
item_length=item_length@entry=0x7fffffffcabc, 
    hfinfo=<error reading variable: Unhandled dwarf _expression_ opcode 0xfa>) at
proto.c:3937
#3  0x00007ffff495cb7b in proto_tree_add_pi (tree=tree@entry=0x7fffec978b60,
hfinfo=hfinfo@entry=0x7ffff6a7c8e0, tvb=tvb@entry=0xf6a140,
start=start@entry=0, 
    length=length@entry=0x7fffffffcafc) at proto.c:3845
#4  0x00007ffff495cbe3 in proto_tree_add_text_node
(tree=tree@entry=0x7fffec978b60, tvb=tvb@entry=0xf6a140, start=start@entry=0,
length=0, length@entry=-1) at proto.c:1083
#5  0x00007ffff495e499 in proto_tree_add_text (tree=tree@entry=0x7fffec978b60,
tvb=tvb@entry=0xf6a140, start=start@entry=0, length=length@entry=-1, 
    format=format@entry=0x7ffff54dfef8 "Addr: %u ## DECOMPRESSION-FAILURE(0)")
at proto.c:1099


Interestingly, if the length is set to >0, we take the other branch in
get_hfi_length() and tvb_captured_length_remaining() is used and we don't throw
an exception.
For length==-1, we call tvb_ensure_captured_length_remaining() and

"we want to ensure that the start offset is not *past* the byte past the end of
the tvbuff"

which leads to the exception.

I think we're going too far in this particular case. My understanding is that
len == -1 means "until the end of the buffer". Going from
offset 0 until the end seems ok to me even if the tvbuff is empty.

What do others think?

Besides, is there any chance to use wmem memory with tvb_new_child_real_data()?

Could we also catch the empty bytecode_tvb up-front and leave without
decompressing anything?

---

      You are receiving this mail because:

• You are watching all bug changes.