[asterisk-bugs] [Asterisk 0017414]: ss_thread calls pri_grab without lock during overlap dial

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17414 
====================================================================== 
Reported By:                pdf
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17414
Category:                   Channels/chan_dahdi
Reproducibility:            sometimes
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.31 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-05-28 02:28 CDT
Last Modified:              2010-05-28 10:29 CDT
====================================================================== 
Summary:                    ss_thread calls pri_grab without lock during overlap
dial
Description: 
Recent changes to chan_dahdi with relation to overlap dialling call
pri_grab without first obtaining a lock.  This is likely to result in lock
leakage due to issue https://issues.asterisk.org/view.php?id=17407.
====================================================================== 

---------------------------------------------------------------------- 
 (0122613) davidw (reporter) - 2010-05-28 10:29
 https://issues.asterisk.org/view.php?id=17414#c122613 
---------------------------------------------------------------------- 
Surely the more serious point is that it tries to do:

p->proceeding = 1;

on a channel private structure that it erroneously thinks it owns
(currently it deadlocks first, but some of the proposals for
DEADLOCK_AVOIDANCE could make it actually do this.

(There are a lot of unlocked accesses to the private structure in that
function, but I could provisionally assume that they are fields that are
readonly once the structure has been created.)

I'm assuming we are talking about this fragment:

			if (p->pri->overlapdial & DAHDI_OVERLAPDIAL_INCOMING) {
				if (p->pri->pri) {		
					if (!pri_grab(p, p->pri)) {
						pri_proceeding(p->pri->pri, p->call, PVT_TO_CHANNEL(p), 0);
						p->proceeding = 1;
						pri_rel(p->pri);
					} else {
						ast_log(LOG_WARNING, "Unable to grab PRI on span %d\n", p->span);
					}
				}
			}


in ss_thread()

I'm not into the internals of chan_dahdi, so I don't know what is safe to
do unlocked, but here it is trying to gain control of a structure. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-05-28 10:29 davidw         Note Added: 0122613                          
======================================================================