[asterisk-dev] race condition on bridge/masquerading?

[Guillermo Winkler]

Russell, thanks for your answer.

I'll open a bug today, hopefully, with a patch (we're testing now a couple
of alternatives).

Regards,
Guille


-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com
[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Russell Bryant
Sent: domingo, 08 de marzo de 2009 02:04 p.m.
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] race condition on bridge/masquerading?


On Mar 7, 2009, at 6:11 PM, Guillermo Winkler wrote:

>                               /* See if the BRIDGEPEER variable  
> needs to be updated */
>                               if (! 
> ast_strlen_zero(pbx_builtin_getvar_helper(c0, "BRIDGEPEER")))
>                                                
> pbx_builtin_setvar_helper(c0, "BRIDGEPEER", c1->name);
>                               if (! 
> ast_strlen_zero(pbx_builtin_getvar_helper(c1, "BRIDGEPEER")))
>                                                
> pbx_builtin_setvar_helper(c1, "BRIDGEPEER", c0->name);
>
> It's not done inside a lock, as it's done inside  
> ast_do_masquerade(struct ast_channel *original) when the clone  
> masquerading member gets destroyed.
>
> In all the crashes I've seen with gdb it's always freeing the  
> BRIDGEPEER variable with a value of local,1 <zombie>, so it was  
> caught in the middle of the masquerading process.
>
> I think access to channel->name should be done inside a lock that  
> also checks for zombieness to be sure we're always touching valid  
> memory.(or better yet, to check the bridge is going through   
> masquerading and stop touching channel members completely)

You are correct.  It is not safe to read ast_channel->name without the  
channel locked.  This is a bug.  Nice work with your analysis.

If you open an issue on bugs.digium.com, we can ensure that this gets  
fixed.

--
Russell Bryant
Digium, Inc. | Senior Software Engineer, Open Source Team Lead
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: www.digium.com & www.asterisk.org





_______________________________________________
--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