Wireshark · Ethereal-dev: [Ethereal-dev] Re: possible crashes in packet-asn1.c and packet-ieee80211.c: snprintf return value i

[ronnie sahlberg <ronniesahlberg@xxxxxxxxx>]

Nice work.

I think requiring 1.2.3 is fine,   those
such as myself with older versions are very few and can live with suboptimal
stability/broken g_snprintf()


If you run   
grep sprintf | sed -e "s/:.*$//" | sort | uniq
in epan and epan/dissectors
you get a lot of hits.

Can you update the wiki and add a section that all these files need to
be audited and fixed up?



On 8/18/05, Ulf Lamping <ulf.lamping@xxxxxx> wrote:
> Hi List!
> 
> I've almost finished the changing from snprintf to g_snprintf.
> 
> This way, we can remove the somewhat bogus snprintf.c/.h files hopefully 
> soon.
> 
> 
> While I'm looking at the handling of the snprintf return values, I've 
> noticed some possible bugs.
> 
> The return value of some snprintf implementations (and g_snprintf too) 
> can return different values if the buffer given was too short, depending 
> on the implementation, see: 
> http://developer.gnome.org/doc/API/2.0/glib/glib-String-Utility-Functions.html#g-snprintf.
> 
> I've checked all appearances of snprintf (and replaced almost any of 
> them with g_snprintf) and found two files which seem to not properly 
> taking care of this return value (and I don't see a simple solution
> myself):
> 
> - epan\dissectors\packet-ieee80211.c (8 times)
> - plugins\asn1\packet-asn1.c (only 1 time)
> 
> a correct sequence could look like:
> 
> retval = snprintf(buffer, bufferlen, format, value);
> if (retval == -1 || retval >= bufferlen) {
>     /* appropriate error handling */
> }
> /* use retval */
> 
> The appearance of -1 will only happen with GLib versions prior to 1.2.3, 
> which will make deep trouble at other places as well, as it won't zero 
> terminate the string.
> 
> We might add a note that we require at least GLib 1.2.3 somewhere.
> 
> 
> Could someone with more knowledge of these dissectors fix this, as it is 
> very certain in my eyes that this could lead to a crash.
> 
> Regards, ULFL
> 
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>