Wireshark-bugs: [Wireshark-bugs] [Bug 8450] New: Decoding of GSM MAP E164 Digits

Date: Fri, 08 Mar 2013 12:54:03 +0000
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 [email protected]
Reporter [email protected]

Created attachment 10215 [details]
Test Case

Build Information:
wireshark 1.9.1 (SVN Rev 47934 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 (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.