https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3884
--- Comment #1 from Mike Morrin <wireshark@xxxxxxxxxxxxxxx> 2009-08-11 23:57:09 PDT ---
(In reply to comment #0)
> Build Information:
> Version 1.2.1ipa30-mm3-3
Copyright 1998-2009 Gerald Combs <gerald@xxxxxxxxxxxxx> 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 with GTK+ 2.16.2, with GLib 2.20.3, with WinPcap (version unknown),
with libz 1.2.3, without POSIX capabilities, with libpcre 7.0, with SMI 0.4.8,
with c-ares 1.6.0, with Lua 5.1, with GnuTLS 2.8.1, with Gcrypt 1.4.4, with MIT
Kerberos, with GeoIP, with PortAudio V19-devel (built Aug 10 2009), with
AirPcap.
Running on Windows XP Service Pack 3, build 2600, with WinPcap version 4.1
beta5
(packet.dll version 4.1.0.1452), based on libpcap version 1.0.0, GnuTLS 2.8.1,
Gcrypt 1.4.4, without AirPcap.
Built using Microsoft Visual C++ 9.0 build 30729
> --
> Load the file:
> http://www.wireshark.org/download/automated/captures/fuzz-2009-08-11-11171.pcap
> Select (for example) packet 3341
> Right click on "Channel Type - (Speech)
> Apply as Filter->Not Selected
>
> You get:
> default:
> DISSECTOR_ASSERT_NOT_REACHED();
> value = 0;
> break;
>
> at line 1023 of proto.c
>
> This is because in packet-bssgp.c at line 1712, BVCI is being added as a 16bit
> integer, but the actual length from the PDU (which is in this case corrupted)
> is passed to proto_tree_add_item() which when adding an integer type, cannot
> handle arbitrary lengths.
>
> While this could be fixed in packet bssgp.c by always passing the expected
> length to proto_tree_add_item(), I think that the correct fix is to change
> proto_tree_new_item() so that it checks that the length is as expected for
> fixed length types, and prints a suitable warning if the length is not as
> expected.
>
The ideal behaviour (from a GSM protocol point of view) would be that if the
given length is too big for the fixed length type, proto_tree_new_item() would
handle the item normally from the beginning of the string, but print an
additional warning about unexpected data octets, it the given length is too
short, it should throw a malformed packet warning.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.