Segfault when clicking on non-GlusterFS packet after expanding GlusterFS payload treeview
Closed this issue · 4 comments
This segfault can be reproduced reliably with the pcap file below.
Steps to reproduce:
- wget http://vmsplice.net/~stefan/glusterfs-dissector-crash.pcap
- wireshark glusterfs-dissector-crash.pcap
- Click on Packet No. 4 (V2 GETSPEC Call) and expand "GlusterFS Handshake" treeview in the payload pane.
- Click on Packet No. 5 and wireshark will segfault.
Reproduced on wireshark 1.8.3-3.fc18 on x86_64.
Hmm, this is not reproducible with the packages for EPEL-6 from http://repos.fedorapeople.org/repos/devos/wireshark-gluster/ (wireshark-1.8.3-1.el6.0.glusterfs.x86_64).
Fedora 18 with wireshark-1.8.3-3.fc18, wireshark-1.8.3-2.fc18 or wireshark-1.8.1-1.fc18 do trigger the crash.
Potentially this issue is caused by the Gluster Handshake protocol. Somewhere there may be an incorrect initialization of a FT_NONE header field. tshark does not have an issue with the same capture....
(gdb) f 1
#1 0x00007ffff4f87760 in construct_match_selected_string (finfo=0x7ffff7ff21c0, edt=0x55555763b230, filter=filter@entry=0x0) at proto.c:6906
6906 abbrev_len = (int) strlen(hfinfo->abbrev);
(gdb) p hfinfo
$2 = (header_field_info *) 0x7ffff7ff1e00
(gdb) p hfinfo->abbrev
$3 = 0x20000000c <Address 0x20000000c out of bounds>
(gdb) p hfinfo->name
$4 = 0x7ffff7ff1fe0 "@\035\377\367\377\177"
(gdb) p hfinfo->blurb
$5 = 0x0
(gdb) p hfinfo->ftenum
There is no member named ftenum.
(gdb) p hfinfo->display
$6 = 0
(gdb) p hfinfo->strings
$7 = (const void *) 0xffffffff
(gdb) p hfinfo->bitmask
$8 = 0
(gdb) p hfinfo->type
$9 = FT_NONE
From doc/README.developer:
FT_NONE No field type. Used for fields that
aren't given a value, and that can only
be tested for presence or absence; a
field that represents a data structure,
with a subtree below it containing
fields for the members of the structure,
or that represents an array with a
subtree below it containing fields for
the members of the array, might be an
FT_NONE field.
Hi Stefan,
after checking again, I am pretty confident that this is a problem in the GTK3 interface of Wireshark. Using a GTK2 version does not trigger the crash. I've built Fedora 18 packages for testing:
The stack-trace looks similar to Fedora Bug 871091, maybe I can find an upstream Wireshark bug for this too.
I am unable to reproduce this crash with the svn version of wireshark from 20121114.
The RPMs (wireshark-1.8.3-2.fc18.0.svn20121114) are also available from my fedora-18 repository.
With that, I consider this issue fixed in upstream wireshark.