Segfault from Race condition when closing channel?

[Harald Welte]

As horiz0n on IRC points out:
00:16   <horiz0n> hehe, calling the c123 from my 9500 communicator crashes openbsc
00:17   <horiz0n> here is the log http://notepad.cc/share/LQ3awCtXz9
00:21   <horiz0n> and here the debug log http://notepad.cc/share/tPJYXo3SJG

<0000> abis_rsl.c:1388 (bts=0,trx=0,ts=1,ss=0) SAPI=0 DATA INDICATION
<0003> gsm_04_08.c:1109 CIPHERING MODE COMPLETE
<0003> gsm_04_08_utils.c:197 Sending Channel Release: Chan: Number: 0 Type: 2
<0004> abis_rsl.c:586 (bts=0,trx=0,ts=1,ss=0) DEACTivate SACCH CMD
<0000> chan_alloc.c:363 (bts=0,trx=0,ts=1,ss=0) Recycling Channel
<0000> abis_rsl.c:1388 (bts=0,trx=0,ts=1,ss=0) SAPI=0 DATA INDICATION
./runbsc.sh: line 6: 1179 Segmentation fault sudo ./bsc_hack -e 1 -d DINP:DNM:DRSL:DRR:DMM:DCC:DRLL:DMNCC:DSMS:DPAG,0:0:0

So what happens: We get a CM Service request, then go through authentication
and ciphering.  At that point, the network decides to release the channel
and the channel is not completely closed yet (only SACCH deactivated) when
we get an incoming SETUP message.

This message is treated as a new message (msc_compl_l3, but it has no
conn->subscr and the code segfaults in trans_find_by_id(subscr=NULL, ...)

So I think there are actually multiple bugs.
1) the channel should not be released at that time
2) we have some kind of a race condition at channel release, where incoming
   messages should either be discarded _or_ should still be processed with
   all the data structures intact.

Cheers,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)