Wireshark-bugs: [Wireshark-bugs] [Bug 2141] Buildbot crash output: fuzz-2007-12-26-32600.pcap
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2141
------- Comment #1 from jyoung@xxxxxxx 2007-12-27 08:25 GMT -------
This is bug in the PCE dissector.
NOTE: I suggest setting a gdb breakpoint at file.c:1009 (the line: "row =
packet_list_append(cf->cinfo.col_data, fdata);".
If execution is allowed to continue into packet_list_append() with the data
returned from the PCE dissector there is a very good chance you will have a
hard time getting control back from a runaway Wireshark.
If you set the breakpoint you will most likely not lock up your machine and you
probably see this warning message:
> Warn Dissector bug, protocol PCE, in packet 1: More than 1000000 items in the tree
-- possible infinite loop
This particular bug is triggered in the dissect_pce_iro_obj() function of
packet-pce.c.
Specfically the problem is in the loop that starts at packet-pce.c:1532
> while(body_obj_len){
>
> l_type = tvb_get_guint8(tvb, *offset2);
> length = tvb_get_guint8(tvb, *offset2+1);
While dissecting the referenced fuzz file, the tvb's *offset2+1 results in the
length variable getting set to a value of 0 (zero).
Subsequent code in the loop doesn't account for a zero value for the length
variable. Consequently the loop doesn't exit by itself. Eventually a
DissectorError is triggered/caught by packet-frame.c which results in the "Warn
Dissector bug" message reported above.
After the DissectorError is generated control returns back to the
add_packet_to_packet_list() function in file.c.
I see a couple possible ways to fix to the packet-pce.c's dissect_pce_iro_obj()
inifinite loop if length == zero problem:
Probably the the most obvious is at the top of the loop to explicitly check
check the variable "length" for a value of zero and gracefully exit the
dissector (with an appropriate message).
Another possibility is to add a test for the zero "length" value in the
"default:" case of the subsequent "switch(type_iro) {" (since the default: case
is what the fuzzed data presented). But this second approach would not stop
the progagation of the zero "length" value to the dissectors called for various
non-default cases. Perhaps those others dissectors already safely can
handle/expect a zero "length" variable.
I hope someone finds this info useful.
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
