Wireshark-bugs: [Wireshark-bugs] [Bug 2169] g_malloc0() call in uat_unesc() (epan/uat.c) is one
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2169
------- Comment #3 from jyoung@xxxxxxx 2008-01-06 18:48 GMT -------
Hello Japp,
I think the uat_unbinstring() is a different use case. It does not return an
ASCII NUL terminated string.
uat_unbinstring() is used to transfrom a hexidecimal encoded string (the si
variable) into into a new array of binary data (the buf varible). If the input
string is well-formed then the out array will be half the size of number of
hexidecimal characters. Each consecutive pair of hexidecimal characters from
the si string will result in a byte value anywhere from 0x00 to 0xff. ASCII
NUL characters (the 0x00) could ultimately be written anywhere within the
g_malloc()ed buffer.
It appears that any normal use of this particular buffer are bounded by the
value of the returned len_p variable.
Now if one attempts to printf("%s") the contents of this particular buffer then
the result will most likely be gibberish. If one appempts to printf("%s") the
buffer and if one is running wireshark in valgrind then the print() will
trigger the valgrind message "Invalid read of size 1" (Unless one of the
hexidecimal pairs of characters just happens to represent as ASCII NUL (0x00)).
;-)
I don't think modifying uat_unbinstring()s' use of "buf= g_malloc(len);" to
"buf= g_malloc(len+1);" and adding a subsequent "buf[len] = (guint8)0;" is
really necessary in this case.
I do believe the original patch as proposed for the uat_unesc() should be
applied.
Thanks.
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
