laforge has submitted this change. ( https://gerrit.osmocom.org/c/osmo-hnbgw/+/37530?usp=email )

Change subject: kpi_ranap: Avoid null pointer de-ref during HNB shutdown ......................................................................

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(-)

Approvals: pespin: Looks good to me, but someone else must approve fixeria: Looks good to me, approved Jenkins Builder: Verified

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);