Fix crash in chan_sip when a core initiated op occurs at the same time as a BYE
authorMatthew Jordan <mjordan@digium.com>
Wed, 10 Apr 2013 14:07:27 +0000 (14:07 +0000)
committerMatthew Jordan <mjordan@digium.com>
Wed, 10 Apr 2013 14:07:27 +0000 (14:07 +0000)
commitcaf4a5f6057c082c195835bc5ae61f75ca9c940e
tree02b34c77d158fbc4d6543ed33e271fa6543406e5
parentd09eeaa8ebb9ccc686263e97d092b1bb1259aee6
Fix crash in chan_sip when a core initiated op occurs at the same time as a BYE

When a BYE request is processed in chan_sip, the current SIP dialog is detached
from its associated Asterisk channel structure. The tech_pvt pointer in the
channel object is set to NULL, and the dialog persists for an RFC mandated
period of time to handle re-transmits.

While this process occurs, the channel is locked (which is good).
Unfortunately, operations that are initiated externally have no way of knowing
that the channel they've just obtained (which is still valid) and that they are
attempting to lock is about to have its tech_pvt pointer removed. By the time
they obtain the channel lock and call the channel technology callback, the
tech_pvt is NULL.

This patch adds a few checks to some channel callbacks that make sure the
tech_pvt isn't NULL before using it. Prime offenders were the DTMF digit
callbacks, which would crash if AMI initiated a DTMF on the channel at the
same time as a BYE was received from the UA. This patch also adds checks on
sip_transfer (as AMI can also cause a callback into this function), as well
as sip_indicate (as lots of things can queue an indication onto a channel).

Review: https://reviewboard.asterisk.org/r/2434/

(closes issue ASTERISK-20225)
Reported by: Jeff Hoppe
........

Merged revisions 385170 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 385173 from http://svn.asterisk.org/svn/asterisk/branches/11

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385174 65c4cc65-6c06-0410-ace0-fbb531ad65f3
channels/chan_sip.c