Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-users: Re: [Wireshark-users] bug on packet-gsm_sms.c short buffer

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Tue, 10 Jun 2008 14:38:44 -0700

On Jun 10, 2008, at 1:00 PM, Jaap Keuter wrote:

It's probably the call to gsm_sms_char_7bit_unpack() that does that.

Or the

	messagebuf[out_len] = '\0';

after it. If out_len is the length of the message, then a maximum- length message will cause an array bounds violation (messagebuf[160] is past the end of messagebuf).

If you do have a sample capture you could share then please open a bug report
with this text and the capture on https://bugs.wireshark.org

...so that we can test a fix. (As per my comment, the right fix would probably be to do:

	#define SMS_MAX_MESSAGE_SIZE	160

		...

	char messagebuf[SMS_MAX_MESSAGE_SIZE + 1];

		...

		out_len =
		    gsm_sms_char_7bit_unpack(fill_bits, length, SMS_MAX_MESSAGE_SIZE,
			tvb_get_ptr(tvb, offset, length), messagebuf);
		messagebuf[out_len] = '\0';

so that the array is 161 bytes long but we only pass 160 to gsm_sms_char_7bit_unpack(). gsm_sms_char_7bit_unpack() appears to do bounds checking, so a message *longer* than 160 bytes won't cause any more of a problem than a 160-byte message does.)