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.