[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 13:45 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.




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

---------------------------------------------------------------------- 
 murf - 03-19-08 13:45  
---------------------------------------------------------------------- 
I propose that I update and apply this patch for 1.4; for trunk & 1.6, we
go the more general route of doing the astobj2 implementation. I honetly
think that using refcounts on peers will cover this problem; I know that
even in the trunk version so far, I've punted on fully tracking peer refs
in the callbacks, but this could be expanded to cover this sort of issue. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
03-19-08 13:45  murf           Note Added: 0084269                          
======================================================================