[asterisk-bugs] [Asterisk 0013014]: [patch] ast_iax2_new() fails to account for a bad situation, deals with another incorrectly
noreply at bugs.digium.com
noreply at bugs.digium.com
Mon Jul 7 16:10:03 CDT 2008
The following issue has been ASSIGNED.
======================================================================
http://bugs.digium.com/view.php?id=13014
======================================================================
Reported By: jpgrayson
Assigned To: russell
======================================================================
Project: Asterisk
Issue ID: 13014
Category: Channels/chan_iax2
Reproducibility: sometimes
Severity: major
Priority: normal
Status: assigned
Asterisk Version: SVN
SVN Branch (only for SVN checkouts, not tarball releases): 1.4
SVN Revision (number only!):
Disclaimer on File?: N/A
Request Review:
======================================================================
Date Submitted: 07-07-2008 15:05 CDT
Last Modified: 07-07-2008 16:10 CDT
======================================================================
Summary: [patch] ast_iax2_new() fails to account for a bad
situation, deals with another incorrectly
Description:
ast_iax2_new() does a tricky dance when allocating an ast_channel. There
are two related problems in ast_iax2_new() regarding this channel
allocation.
For reference, here is the offending code:
ast_mutex_unlock(&iaxsl[callno]);
tmp = ast_channel_alloc(1, state, ...);
ast_mutex_lock(&iaxsl[callno]);
if (!iaxs[callno]) {
if (tmp) {
ast_channel_free(tmp);
}
ast_mutex_unlock(&iaxsl[callno]);
return NULL;
}
The first and most obvious problem in the current implementation is that
there is a case we will unlock callno's mutex prior to returning NULL. This
breaks the protocol for ast_iax2_new() -- users of this function expect
iaxsl[callno] to _always_ be returned locked. When this failure case is
hit, callers of ast_iax2_new() will try to unlock an already unlocked
mutex. Whoops.
The second problem is that this test is incomplete. This code only tests
to see if the chan_iax2_pvt object for callno has become null. A better
test is to check if iaxs[callno] has changed (e.g. i != iaxs[callno]).
There are real-world cases where asterisk is being bombarded with new calls
that this callno may not only be destroyed, but destroyed and reused while
ast_channel_alloc() is being called.
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
07-07-08 16:10 russell Status new => assigned
07-07-08 16:10 russell Assigned To => russell
======================================================================
More information about the asterisk-bugs
mailing list