Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Ethereal-dev: Re: [Ethereal-dev] crash from packet-fc.c

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

From: "Guy Harris" <gharris@xxxxxxxxx>
Date: Thu, 22 Jul 2004 18:29:03 -0700 (PDT)
packet steve said:
>
> Crash in current (22-July) SVN version.
> #0  0xfe633200 in strlen () from /usr/lib/libc.so.1
> #1  0xfe686210 in _doprnt () from /usr/lib/libc.so.1
> #2  0xfe688384 in vsnprintf () from /usr/lib/libc.so.1
> #3  0xfea52614 in col_append_fstr (cinfo=0x758a4, el=-4270640,
> format=0xfee43a30 ", %s") at column-utils.c:288
> #4  0xfeb96408 in dissect_fc (tvb=0x18b6f8, pinfo=0x173748, tree=0x18b590)
> at packet-fc.c:844

Another case where "match_strval()" is being used when it shouldn't be. 
The *only* times "match_strval()" should be used are times when

    1) it is known that all possible ("possible" as in "are in the range
of the underlying raw data", not "possible" as in "the protocol spec
permits that" - a protocol spec doesn't prevent out-of-spec packets
from being put onto a network, it just indicates that they'e
out-of-spec) values are handled by the value_string table;

    2) the code has already determined that the value is one of the ones
in that table;

    3) the code explicitly checks whether "match_strval()" returns null
and handles that in such a way that the return value is not
dereferenced.

That wasn't one of those times; I've checked in a fix to make it use
"val_to_str()" instead.