[asterisk-bugs] [Asterisk 0009520]: realtime prune (and others) may segfault asterisk (timing issue)

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=9520 
====================================================================== 
Reported By:                kryptolus
Assigned To:                russell
====================================================================== 
Project:                    Asterisk
Issue ID:                   9520
Category:                   Channels/chan_sip/Registration
Reproducibility:            always
Severity:                   crash
Priority:                   normal
Status:                     assigned
Asterisk Version:            SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  1.2  
SVN Revision (number only!): 61305 
Disclaimer on File?:        Yes 
Request Review:              
====================================================================== 
Date Submitted:             04-11-2007 07:31 CDT
Last Modified:              03-19-2008 14:04 CDT
====================================================================== 
Summary:                    realtime prune (and others) may segfault asterisk
(timing issue)
Description: 
The function expire_register doesn't do any locking before mucking with the
peer. 
If it gets pre-empted, there's a chance that the peer might be destroyed
before the control returns to expire_register. 

If you execute a "prune realtime peer" at the right time, asterisk will
segfault. It is not limited to just this however, as I have experienced
several segfaults with this signature without any intervention. However,
looking at the code I can only see a problem with the pruning code, I don't
see any possible issues with any other place in sip.

My patch queues up peers to be destroyed and they are ultimately destroyed
from the monitor thread which should guarantee that expire_register cannot
be running  at the same time. The other alternative is to add a check to
expire_register to check if peer is still inside the peer list. However,
that has potential to impact performance because that check would block a
lot of things on every expire.




====================================================================== 

---------------------------------------------------------------------- 
 russell - 03-19-08 14:04  
---------------------------------------------------------------------- 
This patch doesn't make any sense, though.  The problem is that peers are
already reference counted.  If they were ref counted properly, then there
wouldn't be any race conditions or problems to deal with.  This patch is
just hiding the fact that the ref counting is not correct, and is extremely
unlikely to actually completely fix a problem. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
03-19-08 14:04  russell        Note Added: 0084275                          
======================================================================