Bug ID |
10381
|
Summary |
Buildbot crash output: fuzz-2014-08-14-9469.pcap
|
Product |
Wireshark
|
Version |
unspecified
|
Hardware |
x86-64
|
URL |
https://www.wireshark.org/download/automated/captures/fuzz-2014-08-14-9469.pcap
|
OS |
Ubuntu
|
Status |
CONFIRMED
|
Severity |
Major
|
Priority |
High
|
Component |
Dissection engine (libwireshark)
|
Assignee |
[email protected]
|
Reporter |
[email protected]
|
Problems have been found with the following capture file:
https://www.wireshark.org/download/automated/captures/fuzz-2014-08-14-9469.pcap
stderr:
Input file: /home/wireshark/menagerie/menagerie/13-rtcp+rtsp2.pcap.gz
Build host information:
Linux wsbb04 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014
x86_64 x86_64 x86_64 GNU/Linux
Distributor ID: Ubuntu
Description: Ubuntu 14.04.1 LTS
Release: 14.04
Codename: trusty
Buildbot information:
BUILDBOT_REPOSITORY=ssh://[email protected]:29418/wireshark
BUILDBOT_BUILDNUMBER=2923
BUILDBOT_URL=http://buildbot.wireshark.org/trunk/
BUILDBOT_BUILDERNAME=Clang Code Analysis
BUILDBOT_SLAVENAME=clang-code-analysis
BUILDBOT_GOT_REVISION=d9e5021fe79973d00ddd8fcef0bbefbaae63dd0f
Return value: 0
Dissector bug: 0
Valgrind error count: 2
Git commit
commit d9e5021fe79973d00ddd8fcef0bbefbaae63dd0f
Author: Evan Huus <[email protected]>
Date: Tue Aug 12 20:21:19 2014 -0400
hip: fix infinite loop in dissect_hip_tlv
We can't use tree_item == NULL to determine which branch of the previous if
was
hit, since proto_tree_add_item can return NULL when run without tree, which
was
leading to an infinite loop since we were never advancing the offset. Use
the
actual locator_type instead.
Introduced by either g3635d7bed70 or gebff85fdbb although neither of them
directly touch this code path. I'm guess that g3635d7bed70 removed an if
(tree)
guard in some calling function which would have prevented this, but I
haven't
checked. The bug would still have been there before, it just wouldn't have
been
hit because it's only present with a NULL tree. Somebody more familiar with
the
protocol should probably go over a capture or two and make sure this isn't
a
symptom of some other decoding gone awry in the recent changes.
Change-Id: Ie1ce89b16ef667b437c0d99c25e3f3cb2504347d
Reviewed-on: https://code.wireshark.org/review/3564
Reviewed-by: Evan Huus <[email protected]>
Command and args: ./tools/valgrind-wireshark.sh
==24341== Memcheck, a memory error detector
==24341== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==24341== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright
info
==24341== Command:
/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install/bin/tshark
-nr /fuzz/buildbot/clangcodeanalysis/valgrind-fuzz/fuzz-2014-08-14-9469.pcap
==24341==
==24341== Use of uninitialised value of size 8
==24341== at 0xA657C97: ____strtoul_l_internal (strtol_l.c:298)
==24341== by 0x6C505CD: is_rtsp_request_or_reply (packet-rtsp.c:456)
==24341== by 0x6C506B1: dissect_rtspmessage (packet-rtsp.c:737)
==24341== by 0x6C518B9: dissect_rtsp (packet-rtsp.c:1369)
==24341== by 0x66393A3: call_dissector_through_handle (packet.c:626)
==24341== by 0x6639CC4: call_dissector_work (packet.c:713)
==24341== by 0x663A37B: dissector_try_uint_new (packet.c:1145)
==24341== by 0x6D276DB: decode_tcp_ports (packet-tcp.c:4002)
==24341== by 0x6D27A4E: process_tcp_payload (packet-tcp.c:4074)
==24341== by 0x6D2801F: dissect_tcp_payload (packet-tcp.c:1890)
==24341== by 0x6D29CBB: dissect_tcp (packet-tcp.c:4967)
==24341== by 0x66393A3: call_dissector_through_handle (packet.c:626)
==24341==
==24341== Conditional jump or move depends on uninitialised value(s)
==24341== at 0xA657CB8: ____strtoul_l_internal (strtol_l.c:300)
==24341== by 0x6C505CD: is_rtsp_request_or_reply (packet-rtsp.c:456)
==24341== by 0x6C506B1: dissect_rtspmessage (packet-rtsp.c:737)
==24341== by 0x6C518B9: dissect_rtsp (packet-rtsp.c:1369)
==24341== by 0x66393A3: call_dissector_through_handle (packet.c:626)
==24341== by 0x6639CC4: call_dissector_work (packet.c:713)
==24341== by 0x663A37B: dissector_try_uint_new (packet.c:1145)
==24341== by 0x6D276DB: decode_tcp_ports (packet-tcp.c:4002)
==24341== by 0x6D27A4E: process_tcp_payload (packet-tcp.c:4074)
==24341== by 0x6D2801F: dissect_tcp_payload (packet-tcp.c:1890)
==24341== by 0x6D29CBB: dissect_tcp (packet-tcp.c:4967)
==24341== by 0x66393A3: call_dissector_through_handle (packet.c:626)
==24341==
==24341==
==24341== HEAP SUMMARY:
==24341== in use at exit: 1,212,238 bytes in 29,458 blocks
==24341== total heap usage: 630,209 allocs, 600,751 frees, 41,219,497 bytes
allocated
==24341==
==24341== LEAK SUMMARY:
==24341== definitely lost: 5,384 bytes in 165 blocks
==24341== indirectly lost: 36,648 bytes in 49 blocks
==24341== possibly lost: 0 bytes in 0 blocks
==24341== still reachable: 1,170,206 bytes in 29,244 blocks
==24341== suppressed: 0 bytes in 0 blocks
==24341== Rerun with --leak-check=full to see details of leaked memory
==24341==
==24341== For counts of detected and suppressed errors, rerun with: -v
==24341== Use --track-origins=yes to see where uninitialised values come from
==24341== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
[ no debug trace ]
You are receiving this mail because:
- You are watching all bug changes.