openbsc[master]: bsc_api: Fix NULL secondary_lchan access in handle_ass_fail
Pau Espin Pedrol
gerrit-no-reply at lists.osmocom.org
Mon Oct 16 17:51:12 UTC 2017
Patch Set 1:
> Do you conceptually understand when this can happen? If yes,
> please add the rationale to the commit log message
I'm not entirely sure as it's difficult to say only from the bt crash and I don't have deep knowledge about the protocol, but my bet is that it can happen if:
1- gsm0808_assign_req() calls handle_new_assignment() which sends an CHAN ACTIVATE msg and arms T10 timer.
2- ACTIVATE ACK is received (handle_chan_ack), which calls gsm48_send_rr_ass_cmd() which sends an ASSIGNMENT CMD, and doesn't disable/modify T10 timer.
3- T10 timeout is triggered (assignment_t10_timeout()), which sets conn->secondary_lchan = NULL
4- Immediately after, the ASSIGNMENT FAILURE message (which might have been already queued) is processed in handle_ass_fail, and then the crash occurs.
This race condition is not an issue for handle_ass_compl() path because there's this check there which would trigger most probably if secondary_lchan is NULL:
"if (conn->secondary_lchan != msg->lchan)"
If it makes sense for you too then I can add this description to the commit and submit it.
To view, visit https://gerrit.osmocom.org/4277
To unsubscribe, visit https://gerrit.osmocom.org/settings
Gerrit-Owner: Pau Espin Pedrol <pespin at sysmocom.de>
Gerrit-Reviewer: Harald Welte <laforge at gnumonks.org>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: Pau Espin Pedrol <pespin at sysmocom.de>
More information about the gerrit-log