-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3247/
-----------------------------------------------------------

(Updated Feb. 27, 2014, 7:10 a.m.)


Status
------

This change has been marked as submitted.


Review request for Asterisk Developers, Alec Davis and Joshua Colp.


Bugs: ASTERISK-21737
    https://issues.asterisk.org/jira/browse/ASTERISK-21737


Repository: Asterisk


Description
-------

When two RTP channels are in a remote bridge, the remote bridging loop in 
rtp_engine will periodically check to see if the two channels can still be 
bridged. One of the many things it checks is whether or not the codecs have 
changed on the channel. If the codec has changed, it will break out of the loop 
to re-determine which type of bridge is appropriate.

In order to perform this check, the ast_rtp_glue virtual table's get_codec 
callback is called for each channel. The callback implementations assume that 
the channel tech private is valid when called; as such, there has always been 
some code in place to check whether or not the channel pvt is NULL before 
calling. However, this check is insufficient.

The channels are unlocked during the remote bridging loop. It is possible for a 
channel to get masqueraded between the check for the pvt being NULL and the 
actual call to get_codec. When this occurs, the callback is called with a 
ZOMBIE channel, which now has a NULL pvt. Crash.

While this has always been possible in Asterisk 1.8, it is much more likely to 
occur in Asterisk 11 due to the timing changes that occur when getting the 
codec from a channel. As a result, this is much more likely to be reproduced on 
slow, boggy hardware running Asterisk 11 - but fairly rarely otherwise.

Note: This crash was also caught by the various SIP blind transfer tests, in 
addition to the bug report Alec filed.


Diffs
-----

  /branches/1.8/main/rtp_engine.c 408837 
  /branches/1.8/include/asterisk/rtp_engine.h 408837 

Diff: https://reviewboard.asterisk.org/r/3247/diff/


Testing
-------


Thanks,

Matt Jordan

-- 
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Reply via email to