Ethereal-dev: Re: [Ethereal-dev] malformed packet: proto_tree_add_item() cores vs. exceptions?

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Ronnie Sahlberg" <ronnie_sahlberg@xxxxxxxxxxxxxx>
Date: Sat, 22 Mar 2003 08:23:51 +1100
Hm.

proto_tree_add_item() will try to read and parse the scalar from the TVB
itself
and store the FT_UINT32 into a guint32.
It will read as many bytes as specified in length into the guint32 and then
cann proto_tree_add_uint().

If length is >4 then obviously you can not fit the data into a guint32 and
ethereal aborts.

Is the integer scalar value actually of variable length and can it sometimes
be >4 bytes
in the integer?
The code snippet below seems hardcoded to always read it as a 24bit integer
and then
length would always be 3 ?

If the integers are up to 64bit in size, you may try to change it into
FT_UINT64 instead.
Ethereal supports proto_tree_add_item() if 64 bit integers with FT_UINT64
even on platforms with no native 64 bit integer support.
(though tehre is no tvb_get_guint64() or similar call)

Do also look at how proto_tree_add_item() handles FT_UINT64,
I do not remember if it can handle integers <8 bytes in size or if it
only handles integers that are exactly 8 bytes in lkength.
It sould be easy to modify it to handle <=8 byte integers in case
it does not do so already.



----- Original Message -----
From: "Jeff Morriss"
Sent: Saturday, March 22, 2003 6:27 AM
Subject: Re: [Ethereal-dev] malformed packet: proto_tree_add_item() cores
vs. exceptions?


>
> Another (related) question:
>
> proto_tree_add_item() generates a core (from 'assert()') if the item I'm
> adding is, say, a UINT32 but I pass in a length > 4.
>
> I wanted to rewrite "packet-sccp.c" to NOT do:
>
> >   reference = tvb_get_ntoh24(tvb, 0);
> >   proto_tree_add_uint(tree, hf_sccp_dlr, tvb, 0, length, reference);
>
> but instead do:
>
> >     proto_tree_add_item(tree, hf_sccp_dlr, tvb, 0, length, FALSE);
>
> But the problem is that I'm using (what is supposed to be) the length of
> the parameter from the SCCP message, but it can be very wrong if, for
> example, "mtp3.standard" is set incorrectly for the current capture.
>
> The problem I have is that with the existing code I get "malformed
> packets" and with the new code I get cores (which aren't conducive to
> allowing me to change the "mtp3.standard" setting).
>
> Is it possible that 'proto_tree_add_item()' could generate an exception
> (instead of a core) in this (and similar) cases?
>