Wireshark-bugs: [Wireshark-bugs] [Bug 9323] Buildbot crash output: fuzz-2013-10-25-12569.pcap
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Sun, 27 Oct 2013 22:00:57 +0000

changed bug 9323

What Removed Added
Status CONFIRMED RESOLVED
Resolution --- FIXED

Comment # 10 on bug 9323 from 
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > (In reply to comment #6)
> > > > 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).
> > 
> > Actually the problem there is in the g_strlcpy() documentation.  To quote:
> > 
> > "src must be nul-terminated;"!
> 
> Dangit, I assumed that because "At most dest_size - 1 characters will be
> copied" it didn't need to be null-terminated if it was longer than that.
> Welp.

Yeah, I thought the same thing.  Then I happened across that line...

> I think the best way to properly include this logic is to enhance
> string_fvalue_set (ftype-string.c) to correctly handle already_copied==TRUE
> (instead of asserting), then use g_strndup (simpler than g_malloc+strncpy)
> in proto_tree_set_string and pass that into fvalue_set() with
> already_copied=TRUE.

Nice idea.  I was dreading the idea of passing length down to all the ftype_set
functions or researching whether it was safe to (always) move the strdup up a
level.

Fixed in r52905 and put on the roadmap for 1.10.3 and 1.8.11.

You are receiving this mail because:
  • You are watching all bug changes.