Wireshark-bugs: [Wireshark-bugs] [Bug 11360] New: Wireshark crashes during Decode when "Use RTP
| Bug ID |
11360
|
| Summary |
Wireshark crashes during Decode when "Use RTP Timestamp" enabled if initial RTP Timestamp value is not smallest
|
| Product |
Wireshark
|
| Version |
1.12.6
|
| Hardware |
x86-64
|
| OS |
Windows 7
|
| Status |
UNCONFIRMED
|
| Severity |
Major
|
| Priority |
Low
|
| Component |
GTK+ UI
|
| Assignee |
bugzilla-admin@wireshark.org
|
| Reporter |
marcus.taylor@tekcomms.com
|
Created attachment 13728 [details]
Screenshot of a capture that can cause the crash
Build Information:
Version 1.12.6 (v1.12.6-0-gee1fce6 from master-1.12)
Copyright 1998-2015 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.23, with Cairo 1.10.2, with Pango 1.34.0, with
GLib 2.38.0, with WinPcap (4_1_3), with libz 1.2.5, with SMI 0.4.8, with c-ares
1.9.1, with Lua 5.2, without Python, with GnuTLS 3.2.15, with Gcrypt 1.6.2,
without Kerberos, with GeoIP, with PortAudio V19-devel (built Jun 17 2015),
with
AirPcap.
Running on 64-bit Windows 7 Service Pack 1, build 7601, with WinPcap version
4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version 1.0 branch
1_0_rel0b (20091008), GnuTLS 3.2.15, Gcrypt 1.6.2, without AirPcap.
Intel(R) Core(TM) i5-2540M CPU @ 2.60GHz, with 3976MB of physical
memory.
Built using Microsoft Visual C++ 10.0 build 40219
Wireshark is Open Source Software released under the GNU General Public
License.
Check the man page and http://www.wireshark.org for more information.
--
Windows generates a "Wireshark has stopped working" error when attempting to
Decode an RTP Stream with "Use RTP Timestamp" enabled if the first RTP PDU in
the stream has a larger RTP Timestamp value than any subsequent RTP PDU.
Unfortunately, I can't attach the actual PCAP that I used to reproduce this
issue due to privacy concerns, but it may be possible to reproduce with any RTP
stream that has out-of-order packets (delete some PDUs so that the first PDU in
the remaining stream has a larger RTP Timestamp value than a subsequent PDU).
See the attached screen capture that shows that this defect can be reproduced
with as few as 2 RTP PDUs.
I've been able to reproduce this in version 1.10.10, 1.12.5 and 1.12.6.
I believe the issue is in file rtp_player.c, method decode_rtp_stream:
if (first == TRUE) {
/* defined start_timestmp to avoid overflow in timestamp. TODO: handle the
timestamp correctly */
/* XXX: if timestamps (RTP) are missing/ignored try use packet arrive time only
(see also "rtp_time") */
start_timestamp = rp->info->info_timestamp;
start_rtp_time = 0;
rtp_time_prev = start_rtp_time;
first = FALSE;
seq = rp->info->info_seq_num - 1;
}
It sets the reference start_timestamp based on the first RTP PDU in the stream,
but if that RTP PDU does not actually have the smallest value, then that will
cause errors with future calculations.
You are receiving this mail because:
- You are watching all bug changes.
