Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 5284] New: Changing packet filter crashes wireshark

Date: Fri, 8 Oct 2010 05:48:01 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5284

           Summary: Changing packet filter crashes wireshark
           Product: Wireshark
           Version: SVN
          Platform: x86-64
        OS/Version: Ubuntu
            Status: NEW
          Severity: Major
          Priority: Medium
         Component: Wireshark
        AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
        ReportedBy: hasenleithner@xxxxxx


Created an attachment (id=5277)
 --> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=5277)
Trace file triggering the bug

Build Information:
Copyright 1998-2010 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled with GTK+ 2.20.1, (64-bit) with GLib 2.24.1, with libpcap 1.0.0, with
libz 1.2.3.3, with POSIX capabilities (Linux), without libpcre, without SMI,
without c-ares, without ADNS, without Lua, without Python, with GnuTLS 2.8.5,
with Gcrypt 1.4.4, without Kerberos, without GeoIP, without PortAudio, without
AirPcap.

Running on Linux 2.6.32-25-server, with libpcap version 1.0.0, with libz
1.2.3.3, GnuTLS 2.8.5, Gcrypt 1.4.4.

Built using gcc 4.4.3.
--
Steps to reproduce
==================
1. Open the attached file (Meaningless synthetic trace to show the problem)
2. CTRL-G 33 (Go to packet 33)
 Packet 33 now has to be visible in the middle of the top pane.
 Packet 41 must not be visible!
3. Add filter "ip"
4. Wireshark crashes.

Current analysis of the Problem
===============================
Pressing CTRL-G sets the cursor to packet 33. Packet 33 is special in that,
that is that it contains reassembled content of packet 32 and 33 resulting in
two "byte tabs".

After adding the filter, wireshark wants to re-draw the bottom (hex-dump) pane
for packet 33. First, it calls the packet analysis for packet 33, where the IP
parser adds the reassembled content by means of packet_add_new_data_source.
Then, the bottom pane is "drawn" by means of add_main_byte_views.

This calls add_byte_views which calls add_byte_tab. In add_byte_tab,
main_proto_draw.c:693 the first "byte tab" is added to the bottom pane by means
of gtk_container_add. Due to some unknown internal gtk interaction, this
results in the top pane being redrawn.

The top pane has now packet 33 on the top, instead of the middle causing packet
41 to get visible. This triggers Packet 41 being analysed, with the packet
memory being reset! Packet 41 is special in that, that it allocates a large
string (the GET string) with ep_alloc. It therefore overwrites several hundred
bytes of the packet memory.

After being redrawn, the second tab of the bottom pane is drawn. Before,
analysing packet 41, memory for the second "byte tab" was allocated with
packet_add_new_data_source in packet 33. This memory has now been overwritten
by packet 41. This causes gtk_label_new to fail because the name pointer
contains garbage (0x7878787878787878, the 'xx' es from Packet 41).

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.