Capture file causes dissector overflow, outright crash

This issue was migrated from bug 9727 in our old bug tracker.

Original bug information:

Reporter: Brent Bloxam
Status: RESOLVED FIXED
Product: Wireshark
Component: Dissection engine (libwireshark)
OS: OS X 10.9
Platform: x86-64
Version: 1.10.5

Attachments:

bad.pcap: Induces Wireshark crash
backtrace.txt: lldb backtrace on OS X 10.9
crash_bug9727.log: Stack trace with symbols

Brent Bloxam said:

Created attachment 12539 Induces Wireshark crash

Build Information: Version 1.10.5 (SVN Rev 54262 from /trunk-1.10)

Copyright 1998-2013 Gerald Combs <gerald@‍wireshark.org> 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 (64-bit) with GTK+ 2.24.17, with Cairo 1.10.2, with Pango 1.30.1, with GLib 2.36.0, with libpcap, with libz 1.2.3, without POSIX capabilities, without libnl, with SMI 0.4.8, without c-ares, without ADNS, with Lua 5.1, without Python, with GnuTLS 2.12.19, with Gcrypt 1.5.0, with MIT Kerberos, with GeoIP, with PortAudio V19-devel (built Jul 16 2013 19:05:52), with AirPcap.

Running on Mac OS X 10.9.1, build 13B42 (Darwin 13.0.0), with locale .UTF-8, with libpcap version 1.3.0 - Apple version 41, with libz 1.2.5, GnuTLS 2.12.19, Gcrypt 1.5.0, without AirPcap. Intel(R) Core(TM) i7-3720QM CPU @ 2.60GHz

Built using llvm-gcc 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00).

Wireshark is Open Source Software released under the GNU General Public License.

Check the man page and http://www.wireshark.org for more information.

I have tested this with the included build information on Mac OS X as well as Windows XP with the same version number/SVN rev

The capture file will load successfully on Windows but frame number 35 shows STATUS_STACK_OVERFLOW. Clicking on it crashes Wireshark. Scrolling further through the capture it will eventually crash as well trying to show a frame after number 63

On Mac OS X it will crash before being able to display frame number 35

added crash libwireshark osmacos version1.10 labels

Brent Bloxam said:

Created attachment 12540 lldb backtrace on OS X 10.9

I have attached a backtrace from lldb. I am not especially familiar with it

Guy Harris said:

I *suspect* somebody is failing to run out of data, so we're getting IP atop DVB atop MPEG-2 transport stream atop UDP atop IP atop DVB atop....

Is this a problem with MPEG-2 transport stream reassembly, so that headers at some layer aren't getting stripped off?  Or, when reassembling data, are we recursing over packets rather than iterating?  Yes, to iterate is human, and to recurse is divine, but to recurse without tail-recursion eats stack memory.

Evan Huus said:

Only happens on second pass (so this runs clean under tshark most times) and only happens on 1.10 branch (runs clean on master).

Hadriel Kaplan said:

Created attachment 12588 Stack trace with symbols

Yup, it's a bug in 1.10.5 but not 1.11.3.

Attached a stack trace with debug symbols. It doesn't happen immediately on opening the file - only after scrolling down a bit, because the dissector's screwing up on a later packet (frame 1036 I think, or somewhere around there). In addition, if you apply a display filter, it hits the "Too many taps queued" error as well. Looks like mpeg or mp2t is being naughty.

Michael Mann said:

Not sure if this was ever backported to 1.10, but that release has far surpassed it support period. Closing bug.

Guy Harris said:

There were changes to packet-mp2t.c that look as if they'd affect reassembly, so that might be what fixed the infinite recursion.

closed