Wireshark · Ethereal-dev: Re: [Ethereal-dev] Re: Should "dissect_tpkt_encap()" check only its "desegment" argument, rather tha

[Guy Harris <gharris@xxxxxxxxx>]

Gerald Combs wrote:

> I'm concerned that epan/reassemble.c doesn't do a lot of checking for
> "sane" values right now.  For instance it's possible to make Ethereal
> crash by passing a huge frag_data_len value to fragment_add(), as shown
> in bug 421.  Should we have reassemble.c throw an exception if it's
> about to try to allocate an amount of memory that exceeds a certain
> threshold?

Or should it have a "maximum amount of data to reassemble" value, and, 
when asked to reassemble more data than that, just throw away the extra 
data, but continue to do the reassembly work (i.e., keep reassembling, 
just don't actually save the data)?

This might require that a tvbuff have a way of saying "here's how much 
data I'd have if this packet were completely reassembled"; an offset 
that's within that limit, but past the reassembled data, would throw an 
exception different from BoundsError (because the problem isn't the 
result of a too-short snapshot length) *and* different from 
ReportedBoundsError (because the packet's length isn't too small for the 
type of packet, as the offset is within the "real" length of the packet).

That might also be useful in the case where we've turned reassembly off 
- that shouldn't report a malformed packet, either.