----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3247/#review10939 -----------------------------------------------------------
Ship it! Ship It! - Corey Farrell On Feb. 22, 2014, 12:06 p.m., Matt Jordan wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3247/ > ----------------------------------------------------------- > > (Updated Feb. 22, 2014, 12:06 p.m.) > > > 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
