Skip to content

Changes

Started 13 days ago
Queued 9.6 sec
Took 3 min 13 sec on built-in
Lb: Handle SCCP N-NOTICE.ind

Change-Id: I689bf2f2c4311fbc1da92f02c27078a1c00dda1a
Pau Espin Pedrol at
Lb: Handle N-PCSTATE.ind

Change-Id: I16900b9c2b840d4c7d8471c1f69b19601e892b2d
Pau Espin Pedrol at
assignment_fsm: Fix use-after-free of lchan->conn

Scenario:
* A DYNAMIC/OSMOCOM TS in PDCH mode is selected to be used for TCH/F,
  hence the TS is being switched to TCH/F: RF Channel Release is being
  transmitted and waiting to receive RF Channel release ACK. Hence,
  lchan is in state LCHAN_ST_WAIT_TS_READY, and there's a conn with an
  assignment FSM pointing to it in conn->assignment.new_lchan.
  lchan->conn also points to the related conn.
* The BSSMAP SCCP link goes down (link lost), which will terminate the
  conn->fi of all conns related to the MSC peer going down.
  During that teardown, first gscon_pre_term()->gscon_release_lchans()->
  assignment_reset() is called, which sets
  conn->assignment.new_lchan=NULL and calls lchan_release(). This path
  leaves conn->assignment.new_lchan->conn untouched!
* Later in the call path, when finally the bsc_subscr is put() to 0
  references and associated lchan gets its lchan_forget_conn() called,
  it will access lchan->conn which was not freed in the previous step
  mentioned above during assignment_reset().

This patch fixes the issue by adding a lchan_forget_conn() after the
lchan_release() in assignment_reset(), to make sure the conn is no
longer user by the lchan afterwards.

Related: OS#6936
Change-Id: Ifbb9a61cd8a40d953ef5c2b52f9be9ef0dffefa4
Pau Espin Pedrol at