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 8936] New: Fuzz failure: attempt to allocate -1 bytes from

Date: Mon, 15 Jul 2013 16:01:23 +0000
Bug ID 8936
Summary Fuzz failure: attempt to allocate -1 bytes from packet-bacapp.c and/or tvb_generic_clone_offset_len()
Classification Unclassified
Product Wireshark
Version SVN
Hardware All
OS All
Status CONFIRMED
Severity Major
Priority Low
Component Dissection engine (libwireshark)
Assignee [email protected]
Reporter [email protected]

Build Information:
TShark 1.11.0 (SVN Rev 50609 from /trunk)

Copyright 1998-2013 Gerald Combs <[email protected]> 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 GLib 2.34.2, with libpcap, with libz 1.2.7, without
POSIX
capabilities, without libnl, without SMI, with c-ares 1.9.1, with Lua 5.1,
without Python, with GnuTLS 2.12.23, with Gcrypt 1.5.0, without Kerberos,
without GeoIP.

Running on Linux 3.9.2-200.fc18.x86_64, with locale C, with libpcap version
1.3.0, with libz 1.2.7.
        Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz

Built using gcc 4.7.2 20121109 (Red Hat 4.7.2-8).

--
Got another fuzz failure:

~~~
 ERROR
Processing failed. Capture info follows:

  Input file: ../caps/menagerie/public/6118-PDM110.pcap
  Output file: /tmp/fuzz-2013-07-15-17605.pcap

stderr follows:

Input file: ../caps/menagerie/public/6118-PDM110.pcap

Build host information:
Linux mtl-morriss-d1.ulticom.com 3.9.2-200.fc18.x86_64 #1 SMP Mon May 13
13:59:47 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Return value:  133

Dissector bug:  0

Valgrind error count:  0



Subversion revision
------------------------------------------------------------------------
r50610 | morriss | 2013-07-15 09:28:53 -0400 (Mon, 15 Jul 2013) | 6 lines

Fix https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8908 :

As per
http://stackoverflow.com/questions/592620/check-if-a-program-exists-from-a-bash-script
the portable way to find out if a particular command is available is with
"command -v" not
"which".

------------------------------------------------------------------------


Command and args: ./tshark -nVxr


(process:32021): GLib-ERROR **: gmem.c:165: failed to allocate 4294967295 bytes
~~~

Backtrace:

~~~
#0  0x0000003de1c4ec67 in g_logv () from /lib64/libglib-2.0.so.0
#1  0x0000003de1c4ee32 in g_log () from /lib64/libglib-2.0.so.0
#2  0x0000003de1c4d6cc in g_malloc () from /lib64/libglib-2.0.so.0
#3  0x00007f031c9db6eb in tvb_generic_clone_offset_len (len=4294967295,
offset=54, tvb=0x34876a0) at tvbuff.c:486
#4  tvb_clone_offset_len (tvb=0x34876a0, offset=54, len=4294967295) at
tvbuff.c:507
#5  0x00007f031c9db6b4 in tvb_clone_offset_len (tvb=0x348a000, offset=40,
len=4294967295) at tvbuff.c:502
#6  0x00007f031c9db6b4 in tvb_clone_offset_len (tvb=0x321e320, offset=20,
len=4294967295) at tvbuff.c:502
#7  0x00007f031c9db6b4 in tvb_clone_offset_len (tvb=0x348a1e0, offset=12,
len=4294967295) at tvbuff.c:502
#8  0x00007f031c9db6b4 in tvb_clone_offset_len (tvb=0x348a050, offset=8,
len=4294967295) at tvbuff.c:502
#9  0x00007f031c9db6b4 in tvb_clone_offset_len (tvb=tvb@entry=0x348a0f0,
offset=offset@entry=6, len=len@entry=4294967295) at tvbuff.c:502
#10 0x00007f031c9c8731 in fragment_add_seq_work (more_frags=4,
frag_data_len=4294967295, frag_number=<optimized out>, pinfo=0x7fff21c6e2d0,
offset=6, tvb=0x348a0f0, fd_head=0x348f300) at reassemble.c:1732
#11 fragment_add_seq_common (table=table@entry=0x7f031f31cb80
<msg_reassembly_table>, tvb=0x348a0f0, offset=6,
pinfo=pinfo@entry=0x7fff21c6e2d0, id=id@entry=56, data="" out>, 
    frag_number=<optimized out>, frag_number@entry=1,
frag_data_len=frag_data_len@entry=4294967295, more_frags=more_frags@entry=4,
flags=flags@entry=4, orig_keyp=orig_keyp@entry=0x7fff21c6d128)
    at reassemble.c:1899
#12 0x00007f031c9c89b6 in fragment_add_seq_check_work (flags=0, more_frags=4,
frag_data_len=4294967295, frag_number=1, data="" out>, id=56,
pinfo=0x7fff21c6e2d0, offset=<optimized out>, 
    tvb=<optimized out>, table=0x7f031f31cb80 <msg_reassembly_table>) at
reassemble.c:1980
#13 fragment_add_seq_check_work (table=0x7f031f31cb80 <msg_reassembly_table>,
tvb=<optimized out>, offset=<optimized out>, pinfo=0x7fff21c6e2d0, id=56,
data="" out>, frag_number=1, frag_data_len=
    4294967295, more_frags=4, flags=0) at reassemble.c:1959
#14 0x00007f031c9c9018 in fragment_add_seq_check
(table=table@entry=0x7f031f31cb80 <msg_reassembly_table>,
tvb=tvb@entry=0x348a0f0, offset=offset@entry=6,
pinfo=pinfo@entry=0x7fff21c6e2d0, id=id@entry=56, 
    data="" frag_number=frag_number@entry=1,
frag_data_len=4294967295, more_frags=4) at reassemble.c:2024
#15 0x00007f031ca9b3a2 in dissect_bacapp (tvb=0x348a0f0, pinfo=0x7fff21c6e2d0,
tree=0x3487b30) at packet-bacapp.c:10804
#16 0x00007f031c9aac88 in call_dissector_through_handle (handle=0x1d8b190,
tvb=0x348a0f0, pinfo=0x7fff21c6e2d0, tree=0x3487b30, data="" at packet.c:433
~~~


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