Wireshark-bugs: [Wireshark-bugs] [Bug 9323] Buildbot crash output: fuzz-2013-10-25-12569.pcap
Comment # 5
on bug 9323
from Evan Huus
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #1)
> > > It appears the issue is that the format_text* functions in strutil.c have a
> > > small array of buffers that are used as a circular queue to store/return the
> > > "converted" string. These are allocated on "first use", but since they're
> > > static variables in the function, are never freed.
> > >
> > > Evan,
> > > Thoughts?
> >
> > Not the issue in this bug? Asking valgrind for more information gives:
>
> Still worthy of fixing?
Ya, though not a particularly high priority unless it's causing problems.
Probably all three should take a wmem scope as their first argument, and
allocate in that. That is the most flexible approach.
> >
> > ==7729== Uninitialised value was created by a heap allocation
> > ==7729== at 0x4C2A2DB: malloc (in
> > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> > ==7729== by 0x9551DC0: g_malloc (gmem.c:104)
> > ==7729== by 0x4E3E223: buffer_init (buffer.c:35)
> > ==7729== by 0x4E4693B: wtap_open_offline (file_access.c:551)
> > ==7729== by 0x413693: cf_open (tshark.c:3853)
> > ==7729== by 0x40AE2A: main (tshark.c:1930)
> >
> > So I think this is probably at least a partial duplicate of bug #9292... I
> > will dig a little further.
>
> I thought about that too after the fact, but at least this capture only has
> 1 frame, so hopefully the issue is easier to spot.
Ya, I *think* it's an abuse of tvb_get_ptr confused by the fact that wiretap
can overallocate packet buffers, so it turns into an "uninitialised value"
instead of the more logical "read past end of buffer".
You are receiving this mail because:
- You are watching all bug changes.
