openbsc[master]: bsc_api: Fix NULL secondary_lchan access in handle_ass_fail

Pau Espin Pedrol gerrit-no-reply at
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
To unsubscribe, visit

Gerrit-MessageType: comment
Gerrit-Change-Id: Ied5bd90b9c06f27135a2e3c46e40d49d27d9a387
Gerrit-PatchSet: 1
Gerrit-Project: openbsc
Gerrit-Branch: master
Gerrit-Owner: Pau Espin Pedrol <pespin at>
Gerrit-Reviewer: Harald Welte <laforge at>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: Pau Espin Pedrol <pespin at>
Gerrit-HasComments: No

More information about the gerrit-log mailing list