Jeff Morriss
changed
bug 9323
Comment # 7
on bug 9323
from Jeff Morriss
Ermm, isn't the problem that HTTP is adding an FT_STRING ("not necessarily NULL
terminated" according to README.dissector) but proto_tree_add_string() +
proto_tree_set_string() are assuming that it IS NULL terminated (the length
isn't even passed in to the latter function)? If that's the case, have we
really been living with non-NULL-terminated FT_STRINGs having this problem for,
like, ever?
(It took me a while to realize that Valgrind isn't complaining about the result
from format_text() it's complaining about the 'line' (value_ptr).)
(In reply to comment #6)
> This one's weird. The root problem, I think, is that the last line of HTTP
> header is being added to the tree as a pointer retrieved with tvb_get_ptr,
> however the line contained no null terminators. The tree is strduping it for
> display, which of course runs past the end of the packet into uninitialized
> wiretap buffer.
Which reminds me: years ago after I had added the memory scrubbing, I wanted to
add scrubbing to the wiretap buffers too.
> I'm confused that this doesn't happen for every line though, if the packet
> contains no null terminators at all I would think that each line would
> consist of all data to the end of the packet + garbage...
Opening this packet in Wireshark shows that there are some NULLs in prior to
the Accept-Charset header (which is what is causing the complaint here). So
all prior lines hit that NULL and stop.
> I tried to modify the function to use g_strlcpy in order to respect both the
> length *and* any possible null-terminator but that just moved the source of
> the error to the g_strlcpy call. That makes me suspect the length being
> passed in is incorrect, but I cannot track down how.
I didn't try that yet but the length looks OK to me (length is 48 though the
'line' is "Accept-Charset" through the end of the packet and into wiretap's
unused space).
You are receiving this mail because:
- You are watching all bug changes.
