[asterisk-bugs] [Asterisk 0018291]: [patch] When using Realtime gateway definitions, random crashes occur

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18291 
====================================================================== 
Reported By:                nahuelgreco
Assigned To:                rmudgett
====================================================================== 
Project:                    Asterisk
Issue ID:                   18291
Category:                   Channels/chan_mgcp
Reproducibility:            sometimes
Severity:                   crash
Priority:                   normal
Status:                     assigned
Target Version:             1.8.5
Asterisk Version:           SVN 
JIRA:                       SWP-2568 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 294606 
Request Review:              
====================================================================== 
Date Submitted:             2010-11-10 23:18 CST
Last Modified:              2011-04-25 16:49 CDT
====================================================================== 
Summary:                    [patch] When using Realtime gateway definitions,
random crashes occur
Description: 
If you use Realtime MGCP gateways definitions, then Asterisk will randomly
crash. The problem is located in the Realtime gateways pruning process that
runs every 60 seconds. Here unused Realtime gateways are correctly freed
but the gateways linked list is in some cases wrongly relinked, leaving
dangling pointers. The fix is to delete the 3832 line where the 'gprev'
variable is assigned to a freed gateway. 

To illustrate, suppose the following case: you have three gateways in the
list, A->B->C->NULL. B and C will be marked for freeing by
mgcp_prune_realtime_gateway(), but A will persist because it has pending
msgs to send. So:

First loop pass: A will be ignored and gprev will be assigned to A. 

Second loop pass: B will be freed, gprev will be (wrongly) assigned to B
and A->next will be updated to point to C. 

Third loop pass: C will be freed and gprev->next will be updated to the
value in C->next, thats means now B->next will point to NULL. This leaves A
pointing forever to C, a freed gateway. From now the gateways list is
corrupted. 

Note, I never saw Asterisk segfaulting when updating the B->next pointer
in the freed B gateway at the second pass. This makes the problem more
obscure because then Asterisk will segfault at multiple points in
chan_mgcp.c.

A patch is attached with the fix and a little cleanup. The problem is
present in Asterisk 1.8.0 and trunk rev 294606. 

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

---------------------------------------------------------------------- 
 (0134090) svnbot (reporter) - 2011-04-25 16:49
 https://issues.asterisk.org/view.php?id=18291#c134090 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 315349

U   branches/1.8/channels/chan_mgcp.c

------------------------------------------------------------------------
r315349 | rmudgett | 2011-04-25 16:49:02 -0500 (Mon, 25 Apr 2011) | 9
lines

When using MGCP realtime gateway definitions, random crashes occur.

Fixed incorrect linked list node removal for realtime gateways.

(closes issue https://issues.asterisk.org/view.php?id=18291)
Reported by: nahuelgreco
Patches:
      dangling-pointers-when-pruning.patch uploaded by nahuelgreco
(license 162)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=315349 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-04-25 16:49 svnbot         Checkin                                      
2011-04-25 16:49 svnbot         Note Added: 0134090                          
======================================================================