Summary:ASTERISK-16625: schedule_delivery calls ast_bridged_channel() on an unlocked channel
Reporter:Ben Winslow (rain)Labels:
Date Opened:2010-08-27 15:11:43Date Closed:2010-08-27 15:33:22
Versions:Frequency of
Description:Near the beginning of schedule_delivery(), ast_bridged_channel() is called on iaxs[fr->callno]->owner; however, that channel is not locked, which can result in ast_bridged_channel() crashing should owner->tech change to a technology that doesn't implement bridged_channel.  I spoke with briefly with russellb on IRC who agreed that this usage is unsafe.


My crash occurred on (running on a multiprocessor machine), but the problem appears to exist in as well.  Here's a backtrace:

#0  0x00000000 in ?? ()
#1  0x080a2439 in ast_bridged_channel (chan=0xb033fde0) at channel.c:4738
#2  0x07817356 in schedule_delivery (fr=0xb0659de0, updatehistory=1, fromtrunk=0, tsout=0xb6a84b14) at chan_iax2.c:4009
#3  0x0783c96b in socket_process (thread=0xb6b4c460) at chan_iax2.c:11110
#4  0x0783cf9f in iax2_process_thread (data=0xb6b4c460) at chan_iax2.c:11220
ASTERISK-1  0x0815dd84 in dummy_start (data=0xb6b41950) at utils.c:968
ASTERISK-2  0x0049b832 in start_thread () from /lib/libpthread.so.0
ASTERISK-3  0x001e1e0e in clone () from /lib/libc.so.6

(gdb) frame 1
#1  0x080a2439 in ast_bridged_channel (chan=0xb033fde0) at channel.c:4738
4738                    bridged = bridged->tech->bridged_channel(chan, bridged);
(gdb) print bridged->tech->type
$30 = 0x135870b "SIP"
(gdb) print bridged->tech->bridged_channel
$31 = (struct ast_channel *(* const)(struct ast_channel *, struct ast_channel *)) 0

Line 4737 checks that bridged and bridged->tech->bridged_channel are not NULL, so the pointer to bridged->tech must have changed between those instructions.  None of the other threads were doing anything interesting at the time of the core.
Comments:By: Ben Winslow (rain) 2010-08-27 15:12:50

Crap.  This is a duplicate of ASTERISK-16624.  I didn't expect to get a new security token when I hit back in Chromium.