Race condition in app_meetme generates a SIGSEGV

Greetings 

A race condition in function "conf_run" happens
when a caller is joining
a conference just before the last conference use it leaving
it. 

Here's the details:

Say, the last caller "A" is leaving the
conference while another caller
"B"
is joining it.

A's thread is between line 1565 in app_meetme.c and line
1617,
"conflock" mutex is locked. B's thread is
waiting for "conflock" mutex
on line 865 of app_meetme.c.

A's thread is seeing that it is the last user and on line
1582 it calls
"conf_free" releasing the conference. Then A's
thread proceeds to line
1617 to release "conflock".

Once "conflock"" is released, B's thread
grabs it on line 865 and
accesses "conf" structure that has just been
released by A's thread.

Yesterday this race condition crashed my PBX. :(

I think the right solution is to keep conference reference
counting at
the place where "conf_run" is called.

Who is the main caretaker of app_meetme.c? I would like to
work with
this person to develop a fix.

Thanks

-c
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

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

On 5/31/06, Constantine Filin <cfilinintermedia.net> wrote:
> Greetings
>
> A race condition in function "conf_run"
happens when a caller is joining
> a conference just before the last conference use it
leaving it.
>
> Here's the details:
>
> Say, the last caller "A" is leaving the
conference while another caller
> "B"
> is joining it.
>
> A's thread is between line 1565 in app_meetme.c and
line 1617,
> "conflock" mutex is locked. B's thread is
waiting for "conflock" mutex
> on line 865 of app_meetme.c.
>
> A's thread is seeing that it is the last user and on
line 1582 it calls
> "conf_free" releasing the conference. Then
A's thread proceeds to line
> 1617 to release "conflock".
>
> Once "conflock"" is released, B's
thread grabs it on line 865 and
> accesses "conf" structure that has just
been released by A's thread.
>
> Yesterday this race condition crashed my PBX. :(
>
> I think the right solution is to keep conference
reference counting at
> the place where "conf_run" is called.
>
> Who is the main caretaker of app_meetme.c? I would like
to work with
> this person to develop a fix.
>

 This patch went in yesterday to /trunk of app_meetme.c.

--- trunk/apps/app_meetme.c (original)
+++ trunk/apps/app_meetme.c Tue May 30 12:33:37 2006
 -1730,12
+1730,12 
               ast_update_realtime("meetme",
"confno", conf->confno,
"members", members, NULL);
               if (confflags & CONFFLAG_MARKEDUSER)
                       conf->markedusers--;
+               /* Remove ourselves from the list */
+               AST_LIST_REMOVE(&conf->userlist,
user, list);
               if (AST_LIST_EMPTY(&conf->userlist)) {
                       /* close this one when no more users
and no references*/
                       if (!conf->refcount)
                               conf_free(conf);
-               } else {
-                      
AST_LIST_REMOVE(&conf->userlist, user, list);
               }
               /* Return the number of seconds the user was
in the conf */
               snprintf(meetmesecs, sizeof(meetmesecs),
"%d", (int)
(time(NULL) - user->jointime));

 Does this correct your issue? If not, let's post a bug to
bugs.digium.com to get it fixed. Thanks.


-- 
Bird's The Word Technologies, Inc.
http://www.btwtech.com/
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

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

On 5/31/06, BJ Weschke <bweschkegmail.com> wrote:
> On 5/31/06, Constantine Filin <cfilinintermedia.net> wrote:
> > Greetings
> >
> > A race condition in function
"conf_run" happens when a caller is joining
> > a conference just before the last conference use
it leaving it.
> >
> > Here's the details:
> >
> > Say, the last caller "A" is leaving
the conference while another caller
> > "B"
> > is joining it.
> >
> > A's thread is between line 1565 in app_meetme.c
and line 1617,
> > "conflock" mutex is locked. B's
thread is waiting for "conflock" mutex
> > on line 865 of app_meetme.c.
> >
> > A's thread is seeing that it is the last user and
on line 1582 it calls
> > "conf_free" releasing the conference.
Then A's thread proceeds to line
> > 1617 to release "conflock".
> >
> > Once "conflock"" is released,
B's thread grabs it on line 865 and
> > accesses "conf" structure that has
just been released by A's thread.
> >
> > Yesterday this race condition crashed my PBX. :(
> >
> > I think the right solution is to keep conference
reference counting at
> > the place where "conf_run" is called.
> >
> > Who is the main caretaker of app_meetme.c? I would
like to work with
> > this person to develop a fix.
> >


 I just saw your bug #7250 on Mantis. Please see my comment
attached.

-- 
Bird's The Word Technologies, Inc.
http://www.btwtech.com/
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

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