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

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.

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-MessageType: comment
Gerrit-Change-Id: Ied5bd90b9c06f27135a2e3c46e40d49d27d9a387
Gerrit-PatchSet: 1
Gerrit-Project: openbsc
Gerrit-Branch: master
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>
Gerrit-HasComments: No



More information about the gerrit-log mailing list