Wireshark-bugs: [Wireshark-bugs] [Bug 8197] PER dissector crash

Date: Fri, 17 May 2013 14:46:04 +0000

changed bug 8197

What Removed Added
Status CONFIRMED RESOLVED
Resolution --- FIXED

Comment # 16 on bug 8197 from
(In reply to comment #15)
> (In reply to comment #13)
> > (In reply to comment #9)
> > > I get the crash in Fedora 17.  Valgrind complains thus:
> > > 
> > > ~~~
> > > ==1239== Command: /home/morriss/Projects/wireshark/source2/.libs/lt-tshark
> > > -Vx -nr /tmp/fuzz-8197.pcap
> > > ==1239== 
> > > ==1239== Invalid read of size 1
> > > ==1239==    at 0x4104D5: print_hex_data_buffer (print.c:997)
> > > ==1239==    by 0x411E48: print_hex_data (print.c:915)
> > > ==1239==    by 0x4197B6: print_packet (tshark.c:3589)
> > > ==1239==    by 0x41AFAD: process_packet (tshark.c:3198)
> > > ==1239==    by 0x40DE9A: main (tshark.c:2978)
> > > ==1239==  Address 0x9216800 is 0 bytes inside a block of size 1 free'd
> > > ==1239==    at 0x4A07786: free (vg_replace_malloc.c:446)
> > > ==1239==    by 0x35ACC4D50E: g_free (in /usr/lib64/libglib-2.0.so.0.3200.4)
> > > ==1239==    by 0x613ECDB: emem_free_all (emem.c:1239)
> > > ==1239==    by 0x6141828: epan_dissect_run_with_taps (epan.c:218)
> > > ==1239==    by 0x41AEAC: process_packet (tshark.c:3181)
> > > ==1239==    by 0x40DE9A: main (tshark.c:2978)
> > 
> > > 
> > > The first ("invalid read of size 1") is because tvb_new_octet_aligned() is
> > > returning an ep_alloc'd buffer which is then being added as a data source
> > > (add_new_data_source()).  I still need to go back and read about why ep_
> > > allocations started disappearing after dissection is complete but before
> > > we're done displaying what we've dissected.  Anyway, this isn't causing the
> > > crash.
> > 
> > The correct fix for this particular issue (although it is basically a
> > non-issue in practice due to some emem/wmem internals) is to have
> > tvb_new_octet_aligned use the pinfo-scoped pool (pinfo->pool) instead of
> > ephemeral or packet-scoped memory. Unfortunately, this will require passing
> > pinfo pointers into all sorts of functions that don't already have them (in
> > the PER dissector at least) so isn't a simple change.
> 
> Why it just won't allocate memory using glib's g_malloc0(), and later use 
> tvb_set_free_cb(sub_tvb, g_free); ?
> 
> It's how tvb_uncompress() or base64_to_tvb() works....

Right.  Of course.  <sigh>

Fixed like that in r49379 and scheduled for 1.8.7 and 1.10.0rc2.  Thanks for
reminding me/us...

Unfortunately this capture file now shows another error under Valgrind; I think
I'll open a separate bug for that.


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