Treat a length of -1 as a Very Large Length in most cases.

For field types where it doesn't mean "to the end of the tvbuff", treat
it like other negative length values - as if it were unsigned and thus
Very Large and thus likely to be past the end of the tvbuff.  That way,
some of the "we hax0red your SNMP packets" captures, with length fields
of 0xffffffff, report malformed packets rather than dissector bugs.

Change-Id: Id53f828b06b6febe7d79f8539e54523e0b43e5c2
Reviewed-on: https://code.wireshark.org/review/4091
Reviewed-by: Guy Harris <guy@alum.mit.edu>
This commit is contained in:
Guy Harris 2014-09-12 09:59:34 -07:00
parent 887f7f17e8
commit 5ade437ffe
1 changed files with 7 additions and 1 deletions

View File

@ -3880,7 +3880,12 @@ get_hfi_length(header_field_info *hfinfo, tvbuff_t *tvb, const gint start, gint
* of the string", and if the tvbuff if short, we just
* throw an exception.
*
* It's not valid for any other type of field.
* It's not valid for any other type of field. For those
* fields, we treat -1 the same way we treat other
* negative values - we assume the length is a Really
* Big Positive Number, and throw a ReportedBoundsError
* exception, under the assumption that the Really Big
* Length would run past the end of the packet.
*/
switch (hfinfo->type) {
@ -3916,6 +3921,7 @@ get_hfi_length(header_field_info *hfinfo, tvbuff_t *tvb, const gint start, gint
break;
default:
THROW(ReportedBoundsError);
DISSECTOR_ASSERT_NOT_REACHED();
}
*item_length = *length;