Wireshark-bugs: [Wireshark-bugs] [Bug 12461] New: Buildbot crash output: fuzz-2016-05-19-21189.p
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Fri, 20 May 2016 04:20:03 +0000
Bug ID 12461
Summary Buildbot crash output: fuzz-2016-05-19-21189.pcap
Product Wireshark
Version unspecified
Hardware x86-64
URL https://www.wireshark.org/download/automated/captures/fuzz-2016-05-19-21189.pcap
OS Ubuntu
Status CONFIRMED
Severity Major
Priority High
Component Dissection engine (libwireshark)
Assignee bugzilla-admin@wireshark.org
Reporter buildbot-do-not-reply@wireshark.org 

Problems have been found with the following capture file:

https://www.wireshark.org/download/automated/captures/fuzz-2016-05-19-21189.pcap

stderr:
Input file:
/home/wireshark/menagerie/menagerie/14548-asan_heap-oob_4557e4_1285_21aa34231f73e6640365f97a56edb8a3.cap

Build host information:
Linux wsbb04 3.13.0-85-generic #129-Ubuntu SMP Thu Mar 17 20:50:15 UTC 2016
x86_64 x86_64 x86_64 GNU/Linux
Distributor ID:    Ubuntu
Description:    Ubuntu 14.04.4 LTS
Release:    14.04
Codename:    trusty

Buildbot information:
BUILDBOT_REPOSITORY=ssh://wireshark-buildbot@code.wireshark.org:29418/wireshark
BUILDBOT_BUILDNUMBER=131
BUILDBOT_URL=http://buildbot.wireshark.org/wireshark-2.0/
BUILDBOT_BUILDERNAME=Fuzz Test
BUILDBOT_SLAVENAME=fuzz-test
BUILDBOT_GOT_REVISION=25dfe95163301af07e6a3032e16fb03c406cef8c

Return value:  0

Dissector bug:  0

Valgrind error count:  1



Git commit
commit 25dfe95163301af07e6a3032e16fb03c406cef8c
Author: Anthony Coddington <anthony.coddington@endace.com>
Date:   Mon Apr 18 13:44:35 2016 +1200

    pcap-common: Account for padding in ENCAP_ERF len and caplen

    Set len and caplen in pcap_read_post_process to actual wlen/payload length
like for native ERF.
    This fixes padding incorrectly showing as an Ethernet trailer or equivalent
as
    well as packet length calculations being incorrect.

    Fix up rlen when writing ENCAP_ERF so it isn't longer than the actual
record
    length. This differs from native ERF behaviour which pads the record
instead
    but there is currently no non-hackish way to do this for pcap/pcap-ng.

    Note: This means records captured from a DAG card in Wireshark (or old
    PCAP(-NG) files opened) will have padding stripped when saved as PCAP(-NG)
and
    thus cannot be transmitted when converted to native ERF without aligning
first.
    However, if the file is saved as native ERF originally the padding will be
    preserved (and zeroed). Given that extension header write support was very
    broken and transmission of PCAP(-NG) is not supported without conversion
this
    is not expected to have been common.

    Ping-Bug: 3606
    Change-Id: I49dce03984d7f07431b6eb7e16a993aeb571f288
    Reviewed-on: https://code.wireshark.org/review/15359
    Petri-Dish: Michael Mann <mmann78@netscape.net>
    Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
    Reviewed-by: Michael Mann <mmann78@netscape.net>
    (cherry picked from commit c38f4e1391cc914271e168606cc1e8adcc973bd8)
    Reviewed-on: https://code.wireshark.org/review/15428
    Reviewed-by: Anders Broman <a.broman58@gmail.com>


Command and args: ./tools/valgrind-wireshark.sh 

==7650== Memcheck, a memory error detector
==7650== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==7650== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==7650== Command:
/home/wireshark/builders/wireshark-2.0-fuzz/fuzztest/install/bin/tshark -nr
/fuzz/buildbot/fuzztest/valgrind-fuzz-2.0/fuzz-2016-05-19-21189.pcap
==7650== 
==7650== Conditional jump or move depends on uninitialised value(s)
==7650==    at 0x6889E0C: AirPDcapDecryptWPABroadcastKey (airpdcap.c:318)
==7650==    by 0x688A3D2: AirPDcapRsna4WHandshake (airpdcap.c:1405)
==7650==    by 0x688AB72: AirPDcapScanForKeys (airpdcap.c:564)
==7650==    by 0x688AD9F: AirPDcapPacketProcess (airpdcap.c:696)
==7650==    by 0x6C08212: dissect_ieee80211_common (packet-ieee80211.c:17815)
==7650==    by 0x6C0A065: dissect_ieee80211 (packet-ieee80211.c:18423)
==7650==    by 0x684688E: call_dissector_through_handle (packet.c:618)
==7650==    by 0x6847224: call_dissector_work (packet.c:706)
==7650==    by 0x6847A1B: dissector_try_uint_new (packet.c:1163)
==7650==    by 0x6B1A645: dissect_frame (packet-frame.c:499)
==7650==    by 0x684688E: call_dissector_through_handle (packet.c:618)
==7650==    by 0x6847224: call_dissector_work (packet.c:706)
==7650== 
==7650== 
==7650== HEAP SUMMARY:
==7650==     in use at exit: 1,039,567 bytes in 28,330 blocks
==7650==   total heap usage: 239,420 allocs, 211,090 frees, 31,160,709 bytes
allocated
==7650== 
==7650== LEAK SUMMARY:
==7650==    definitely lost: 2,908 bytes in 125 blocks
==7650==    indirectly lost: 36,448 bytes in 48 blocks
==7650==      possibly lost: 0 bytes in 0 blocks
==7650==    still reachable: 1,000,211 bytes in 28,157 blocks
==7650==         suppressed: 0 bytes in 0 blocks
==7650== Rerun with --leak-check=full to see details of leaked memory
==7650== 
==7650== For counts of detected and suppressed errors, rerun with: -v
==7650== Use --track-origins=yes to see where uninitialised values come from
==7650== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

[ no debug trace ]

You are receiving this mail because:
  • You are watching all bug changes.