[bugzilla-daemon@xxxxxxxxxxxxx]

Bug ID	8450
Summary	Decoding of GSM MAP E164 Digits
Classification	Unclassified
Product	Wireshark
Version	1.9.x (Experimental)
Hardware	All
OS	All
Status	UNCONFIRMED
Severity	Trivial
Priority	Low
Component	Dissection engine (libwireshark)
Assignee	bugzilla-admin@wireshark.org
Reporter	vineethvijaysv@gmail.com

Created attachment 10215 [details]
Test Case

Build Information:
wireshark 1.9.1 (SVN Rev 47934 from /trunk)

Copyright 1998-2013 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 (32-bit) with GTK+ 2.22.0, with Cairo 1.10.0, with Pango 1.28.2, with
GLib 2.26.1, with libpcap, with libz 1.2.3.4, without POSIX capabilities,
without libnl, without SMI, without c-ares, without ADNS, without Lua, without
Python, without GnuTLS, without Gcrypt, without Kerberos, without GeoIP,
without
PortAudio, with AirPcap.

Running on Linux 2.6.35-22-generic, with locale en_IN, with libpcap version
1.1.1, with libz 1.2.3.4, without AirPcap.

Built using gcc 4.4.5.
--
Attachment contains some CAMEL packets bearing SMSC digits of just two octets.
Wireshark is attempting the decode with dissect_gsm_map_msisdn, but hits a lag
when trying to dissect the country code [dissect_e164_cc ()]

The issue seems to occur when retrieval of second octet is attempted, but the
buffer itself is of one octet. An additional check seems to correct the issue,
but not sure whether this will break something else:

--- packet-e164.c_original      2013-02-22 17:17:53.783747672 +0530
+++ packet-e164.c       2013-03-08 18:17:59.568052678 +0530
@@ -426,8 +426,10 @@
                cc = cc << 4;
                cc = cc | (address_digit_pair &0xf0)>>4;
                cc = cc << 4;
+                if ( tvb_length(tvb) - cc_offset - 1 > 0 ) {
                address_digit_pair = tvb_get_guint8(tvb, cc_offset+1);
                cc = cc | (address_digit_pair &0x0f);
+                }

        }

Regarding the validity of the packet itself , as far as I can tell an
RP-Destination address can have a minimum of 2 octets (which is the case
here.).

---

      You are receiving this mail because:

• You are watching all bug changes.