Fix a race condition in the SIP packet scheduler which could cause a crash.
commitc4602a89f2eb6bc643da02d1967eff1319a0fe74
authormmichelson <mmichelson@614ede4d-c843-0410-af14-a771ab80d22e>
Fri, 14 Mar 2008 16:44:08 +0000 (14 16:44 +0000)
committermmichelson <mmichelson@614ede4d-c843-0410-af14-a771ab80d22e>
Fri, 14 Mar 2008 16:44:08 +0000 (14 16:44 +0000)
tree99d5222ebb559e75f11360d31de99d48eeaf82b2
parent68d578ccd4fc66457adc4bc60529516bcad139fc
Fix a race condition in the SIP packet scheduler which could cause a crash.

chan_sip uses the scheduler API in order to schedule retransmission of reliable
packets (such as INVITES). If a retransmission of a packet is occurring, then the
packet is removed from the scheduler and retrans_pkt is called. Meanwhile, if
a response is received from the packet as previously transmitted, then when we
ACK the response, we will remove the packet from the scheduler and free the packet.

The problem is that both the ACK function and retrans_pkt attempt to acquire the
same lock at the beginning of the function call. This means that if the ACK function
acquires the lock first, then it will free the packet which retrans_pkt is about to
read from and write to. The result is a crash.

The solution:

1. If the ACK function fails to remove the packet from the scheduler and the retransmit
   id of the packet is not -1 (meaning that we have not reached the maximum number of
   retransmissions) then release the lock and yield so that retrans_pkt may acquire the
   lock and operate.

2. Make absolutely certain that the ACK function does not recursively lock the lock in
   question. If it does, then releasing the lock will do no good, since retrans_pkt will
   still be unable to acquire the lock.

(closes issue #12098)
Reported by: wegbert
(closes issue #12089)
Reported by: PTorres
Patches:
      12098-putnopvutv3.patch uploaded by putnopvut (license 60)
Tested by: jvandal

git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@108737 614ede4d-c843-0410-af14-a771ab80d22e
channels/chan_sip.c