Ethereal-dev: Re: [ethereal-dev] packet-snmp.c patch to handle zero length context names

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

From: Guy Harris <gharris@xxxxxxxxxxxx>
Date: Thu, 29 Jun 2000 02:31:30 -0700
On Wed, Jun 28, 2000 at 10:54:09PM +0200, Juergen Schoenwaelder wrote:
> This following prevents a core dump when you dissect SNMPv3 packets
> with a zero-length context name (which is legal according to RFC
> 2572).

Elsewhere in "packet-snmp.c", we, in effect, rely on "%.*s" not to print
any characters if the precision argument supplied is 0.

In addition, "%.*s" should probably be used for counted strings; there's
no guarantee that what "asn1_octet_string_value_decode()" returns is
'\0'-terminated.

Thus, assuming the formatting routine we use doesn't dereference the
pointer handed to it if the precision argument supplied to "%.*s" is
zero (which we should, perhaps, not rely on, unless the ANSI C standard
says it's so - but, if we shouldn't, we have other calls to fix as
well)

diff -c -r1.40 packet-snmp.c
*** packet-snmp.c	2000/06/28 05:15:13	1.40
--- packet-snmp.c	2000/06/29 09:30:30
***************
*** 1603,1609 ****
  		}
  		if (snmp_tree) {
  			proto_tree_add_text(snmp_tree, NullTVB, offset, length,
! 			    "Context Name: %s", cname);
  		}
  		g_free(cname);
  		offset += length;
--- 1603,1609 ----
  		}
  		if (snmp_tree) {
  			proto_tree_add_text(snmp_tree, NullTVB, offset, length,
! 			    "Context Name: %.*s", cname_length, cname);
  		}
  		g_free(cname);
  		offset += length;

should fix the problem, and should also handle the string not being
'\0'-terminated (which means we should make that change in *any* case;
I'll check it in).

> [Also note that a context name can contain arbitrary octets including
>  \0. The %s format specifier thus does not return useful results in
>  all possible cases.]

Is it expected to be a "human-readable" string in all cases, or only in
some cases?

And if it contains '\0', does that mean it's not intended to be
human-readable?

If it's sometimes but not always intended to be human-readable, perhaps
we should check whether all the octets in it correspond to printable
characters and, if they're not all printable characters, display it as
hex, otherwise display it as text.