[asterisk-bugs] [Asterisk 0012162]: sipsock_read using unsafe structure

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12162 
====================================================================== 
Reported By:                norman
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   12162
Category:                   Channels/chan_sip/General
Reproducibility:            random
Severity:                   minor
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.4.18 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             03-06-2008 13:09 CST
Last Modified:              05-05-2008 09:16 CDT
====================================================================== 
Summary:                    sipsock_read using unsafe structure
Description: 
While trying to track down a series of crashes after
http://bugs.digium.com/view.php?id=12063 was closed, I
noticed a crash happened after I saw this on the console:

    We could NOT get the channel lock for SIPstation032-06d12ea0! 

Running under valgrind, I noticed that sipsock_read was trying to lock
p->owner (via ast_channel_trylock in the loop), and when this failed, it
unlocks "p" then proceeds to use "p" and even p->owner (also unlocked and
potentially free'd.) Valgrind noted, in the case of the crash, this section
of code was accessing unallocated memory. 

I believe this happens rarely, when a channel has been closed at an
inconvient time. After I applied this quick patch and the patch from
http://bugs.digium.com/view.php?id=11940, I've never seen this problem while
under valgrind after over a week
of testing.
====================================================================== 

---------------------------------------------------------------------- 
 file - 05-05-08 09:16  
---------------------------------------------------------------------- 
qwell: In response to your poke on Friday re this yes I agree this will fix
the issue in question and should be fine. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
05-05-08 09:16  file           Note Added: 0086406                          
======================================================================