Change in osmo-msc[master]: libmsc/gsm_04_11.c: properly handle TP-User-Data-Length

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.

Vadim Yanitskiy gerrit-no-reply at lists.osmocom.org
Tue Apr 16 10:04:27 UTC 2019


Vadim Yanitskiy has uploaded this change for review. ( https://gerrit.osmocom.org/13655


Change subject: libmsc/gsm_04_11.c: properly handle TP-User-Data-Length
......................................................................

libmsc/gsm_04_11.c: properly handle TP-User-Data-Length

As per 3GPP TS 03.40, section 9.2.3.16 "TP-User-Data-Length (TP-UDL)",
if the TP-User-Data is coded using the GSM 7-bit default alphabet,
the TP-User-Data-Length field indicates the *number of septets*
within the TP-User-Data field to follow. Otherwise, i.e. in case
of 8-bit or UCS-2 encoded data, the *number of octets* is indicated.

Since we store the original TP-UDL value (as received), we might
need to convert septets to octets before passing it to memcpy().
Otherwise this would lead to a buffer overrun.

Also, as we receive TPDU from untrusted source (i.e. subscriber),
the TP-UDL value needs to be checked against the corresponding
maximum (160 septets or 140 octets) and truncated if needed.

Please note that buffer overrun is still possible, e.g. when an
indicated TP-UDL value is grather than the remaining TPDU length.
Preventing this would require adding an additional check.

Change-Id: I4b08db7665e854a045129e7695e2bdf296df1688
Depends-on: (core) I54f88d2908ac47228813fb8c049f4264e5145241
---
M src/libmsc/gsm_04_11.c
1 file changed, 29 insertions(+), 12 deletions(-)



  git pull ssh://gerrit.osmocom.org:29418/osmo-msc refs/changes/55/13655/1

diff --git a/src/libmsc/gsm_04_11.c b/src/libmsc/gsm_04_11.c
index 434f878..6eea662 100644
--- a/src/libmsc/gsm_04_11.c
+++ b/src/libmsc/gsm_04_11.c
@@ -42,6 +42,7 @@
 #include <osmocom/gsm/gsm_utils.h>
 #include <osmocom/gsm/gsm0411_utils.h>
 #include <osmocom/gsm/protocol/gsm_04_11.h>
+#include <osmocom/gsm/protocol/gsm_03_40.h>
 
 #include <osmocom/msc/debug.h>
 #include <osmocom/msc/gsm_data.h>
@@ -559,19 +560,35 @@
 		rc = GSM411_RP_CAUSE_MO_NET_OUT_OF_ORDER;
 		goto out;
 	}
-	gsms->user_data_len = *smsp++;
-	if (gsms->user_data_len) {
-		memcpy(gsms->user_data, smsp, gsms->user_data_len);
 
-		switch (sms_alphabet) {
-		case DCS_7BIT_DEFAULT:
-			gsm_7bit_decode_n(gsms->text, sizeof(gsms->text), smsp,
-					  gsms->user_data_len);
-			break;
-		case DCS_8BIT_DATA:
-		case DCS_UCS2:
-		case DCS_NONE:
-			break;
+	/* As per 3GPP TS 03.40, section 9.2.3.16, TP-User-Data-Length (TP-UDL)
+	 * may indicate either the number of septets, or the number of octets,
+	 * depending on Data Coding Scheme. We store TP-UDL value as-is,
+	 * so this should be kept in mind to avoid buffer overruns. */
+	gsms->user_data_len = *smsp++;
+	if (gsms->user_data_len > 0) {
+		if (sms_alphabet == DCS_7BIT_DEFAULT) {
+			/* TP-UDL is indicated in septets (up to 160) */
+			if (gsms->user_data_len > GSM340_UDL_SPT_MAX) {
+				LOG_TRANS(trans, LOGL_NOTICE,
+					  "TP-User-Data-Length %u (septets) "
+					  "is too big, truncating to %u\n",
+					  gsms->user_data_len, GSM340_UDL_SPT_MAX);
+				gsms->user_data_len = GSM340_UDL_SPT_MAX;
+			}
+			memcpy(gsms->user_data, smsp, gsm_get_octet_len(gsms->user_data_len));
+			gsm_7bit_decode_n(gsms->text, sizeof(gsms->text),
+					  smsp, gsms->user_data_len);
+		} else {
+			/* TP-UDL is indicated in octets (up to 140) */
+			if (gsms->user_data_len > GSM340_UDL_OCT_MAX) {
+				LOG_TRANS(trans, LOGL_NOTICE,
+					  "TP-User-Data-Length %u (octets) "
+					  "is too big, truncating to %u\n",
+					  gsms->user_data_len, GSM340_UDL_OCT_MAX);
+				gsms->user_data_len = GSM340_UDL_OCT_MAX;
+			}
+			memcpy(gsms->user_data, smsp, gsms->user_data_len);
 		}
 	}
 

-- 
To view, visit https://gerrit.osmocom.org/13655
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-msc
Gerrit-Branch: master
Gerrit-MessageType: newchange
Gerrit-Change-Id: I4b08db7665e854a045129e7695e2bdf296df1688
Gerrit-Change-Number: 13655
Gerrit-PatchSet: 1
Gerrit-Owner: Vadim Yanitskiy <axilirator at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20190416/25cf5d13/attachment.htm>


More information about the gerrit-log mailing list