[asterisk-bugs] [Asterisk 0003312]: [patch] Race condition in zaptel.c causes a kernel panic & fix

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=3312 
====================================================================== 
Reported By:                klicTel
Assigned To:                markster
====================================================================== 
Project:                    Asterisk
Issue ID:                   3312
Category:                   Core/General
Reproducibility:            always
Severity:                   crash
Priority:                   normal
Status:                     closed
Asterisk Version:           CVS 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             01-10-2005 15:09 CST
Last Modified:              06-07-2008 10:47 CDT
====================================================================== 
Summary:                    [patch] Race condition in zaptel.c causes a kernel
panic & fix
Description: 
Environment: Dual xeon servers (Dell 2850 or Vision),
             Asterisk 1.0.3 or latest CVS, Redhat enterprise ES3 update 3
or latest stock kernel 2.4.28, or fedora 2.6 kernel,
             TE410P

Kernel Panic trace: Attached file panic.txt

When Zaptel/Asterisk receives a high number of simultaneous calls, the
pointer chan->curtone can become NULL while the function
__zt_getbuf_chunk() tries to use it (line 4848). It might seem impossible
since this condition is tested right above that line, but it does happen
that between the time the test 'if (ms->curtone &&...' is performed and the
time curtone is used, it gets set to NULL by the function zt_chan_ioctl()
(line 4099). Examinig the code, you notice that no lock on the chan is
performed during that operation. The calls to __zt_getbuf_chunk() are all
within lock/unlock. By simply adding the protection in zt_chan_ioctl(), we
eliminated the problem. Here is the fix:
4098a4099
>               spin_lock_irqsave(&chan->lock, flags);
4099a4101
>               spin_unlock_irqrestore(&chan->lock, flags);


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

---------------------------------------------------------------------- 
 svnbot - 06-07-08 10:47  
---------------------------------------------------------------------- 
Repository: dahdi
Revision: 545

U   branches/v1-0/zaptel.c

------------------------------------------------------------------------
r545 | russell | 2008-06-07 10:47:20 -0500 (Sat, 07 Jun 2008) | 2 lines

lock some parameters (bug http://bugs.digium.com/view.php?id=3312)

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

http://svn.digium.com/view/dahdi?view=rev&revision=545 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
06-07-08 10:47  svnbot         Checkin                                      
06-07-08 10:47  svnbot         Note Added: 0087991                          
======================================================================