laforge has uploaded this change for review.
kpi_ranap: Avoid null pointer de-ref during HNB shutdown
In the downlink path, we cannot assume map->hnb_ctx is always
non-NULL. If the HNB has just disconnected, it might be NULL,
while we're still processing downlink messages from the CN which
were sent by it before it realized that HNB was gone.
Closes: SYS#7010
Change-Id: I9a304b9e0cbc18dbf7b699f4aae6b91ca0c16173
---
M src/osmo-hnbgw/kpi_ranap.c
1 file changed, 25 insertions(+), 0 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-hnbgw refs/changes/30/37530/1
diff --git a/src/osmo-hnbgw/kpi_ranap.c b/src/osmo-hnbgw/kpi_ranap.c
index 59631cf..d731c5f 100644
--- a/src/osmo-hnbgw/kpi_ranap.c
+++ b/src/osmo-hnbgw/kpi_ranap.c
@@ -179,6 +179,13 @@
void kpi_ranap_process_dl(struct hnbgw_context_map *map, ranap_message *ranap)
{
+ if (map->hnb_ctx == NULL) {
+ /* This can happen if the HNB has disconnected and we are processing downlink messages
+ * from the CN which were already in flight before the CN side has realized the HNB
+ * is gone. */
+ return;
+ }
+
switch (ranap->procedureCode) {
case RANAP_ProcedureCode_id_RAB_Assignment: /* RAB ASSIGNMENT REQ (8.2) */
kpi_ranap_process_dl_rab_ass_req(map, ranap);
@@ -405,6 +412,9 @@
void kpi_ranap_process_ul(struct hnbgw_context_map *map, ranap_message *ranap)
{
+ /* we should never be processing uplink messages from a non-existant HNB */
+ OSMO_ASSERT(map->hnb_ctx);
+
switch (ranap->procedureCode) {
case RANAP_ProcedureCode_id_RAB_Assignment: /* RAB ASSIGNMENT REQ (8.2) */
kpi_ranap_process_ul_rab_ass_resp(map, ranap);
To view, visit change 37530. To unsubscribe, or for help writing mail filters, visit settings.