Attention is currently required from: laforge, pespin.
2 comments:
File src/libmsc/sgs_iface.c:
the questions is what such proprietary formats are, how they look like, used by whom, and why there […]
We do try to parse it again (see below). We also use it to extract the gummei but as it seems the result is only used to name an FSM. The mme_fqdn is also used in the VLR. It is probably difficult to trace if it is really safe to use an arbitrary string as MME name.
Patch Set #2, Line 204: OSMO_ASSERT(osmo_parse_mme_domain(&gummei, mme_fqdn) == 0);
As it seems it gets even more problematic here: Let's assume we have called decode_mme_name before with a SGSAP_IE_MME_NAME that was not acceted by osmo_parse_mme_domain, so we took the memcpy path and just copied the value. Now we call sgs_mme_fqdn_received here with that value. Since the value didn't change, osmo_parse_mme_domain will reject it and the OSMO_ASSERT will crash the MSC.
The OSMO_ASSERT was introduced with:
```
commit 0df904dea9106587f40ec379e9cc05ea251beb7e
Author: Harald Welte <laforge@gnumonks.org>
Date: Mon Dec 3 11:00:04 2018 +0100
```
This is much earlier than:
```
commit e2bd9eb37d8160b436a5a1bffc14690321f40ae6
Author: Omar Ramadan <omar.ramadan93@gmail.com>
Date: Fri Apr 12 09:03:39 2019 -0700
```
So from what I can see the alternate path was never actively used, as it would have crashed the MSC. If this is true I would see that as an argument for removing the alternate path altogether as it has never worked.
To view, visit change 43237. To unsubscribe, or for help writing mail filters, visit settings.