Wireshark-users: Re: [Wireshark-users] bug on packet-gsm_sms.c short buffer
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
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.)