NULL-pointer de-reference of HNB context after HNB de-registration / reject
I've looked a bit at the hnbap code in osmo-hnbw, and I think there's a bug related to the hnb_context.
- we allocate a hnb_context when accept()ing the SCTP connection
- we release (free) the context not just when the SCTP connection is down, but also when
- not being able to transmit a HNB-REGISTER-REJ
- receiving a HNB-DE-REGISTER-REQ (which is what we receive here)
However, if a remote peer would choose to send us any additional HNBAP or RUA messages over the same association later on,
hnb_read_cb() would unconditionally de-reference hnb, which is now a NULL-pointer, in
struct hnb_context *hnb = osmo_stream_srv_get_data(conn); ... msg->dst = hnb; ... hnb->hnbap_stream = msgb_sctp_stream(msg); ... hnb->rua_stream = msgb_sctp_stream(msg);
So either we guard against this and no longer accept traffic on such an SCTP association, or we don't free the HNB context before the assoc/socket is closed.
I think the latter is the better solution, as we are seeing some 3rd party HNB which are re-using the same association to continue to talk to the HNBGW without shutting it down and creating a new connection.
sigsegv reproduced with this TTCN3 test:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/29325 hnbgw: Introduce test TC_hnb_reregister_reuse_sctp_assoc
Program received signal SIGSEGV, Segmentation fault. 0x000055ee5507a77c in hnb_read_cb () #0 0x000055ee5507a77c in hnb_read_cb () #1 0x00007f193271120a in ?? () from /usr/lib/x86_64-linux-gnu/libosmonetif.so.8 #2 0x00007f193273a0f8 in ?? () from /usr/lib/x86_64-linux-gnu/libosmocore.so.19 #3 0x00007f193273a217 in osmo_select_main_ctx () from /usr/lib/x86_64-linux-gnu/libosmocore.so.19 #4 0x000055ee5507bc2c in main () (gdb) quit A debugging session is active.