[asterisk-bugs] [Asterisk 0014000]: [patch] Wrong usage of sscanf with use of uninitialized variable caused accidental parsing of RTP/SAVP

Asterisk Bug Tracker noreply at bugs.digium.com
Tue Dec 2 11:42:05 CST 2008


The following issue has been RESOLVED. 
====================================================================== 
http://bugs.digium.com/view.php?id=14000 
====================================================================== 
Reported By:                folke
Assigned To:                Corydon76
====================================================================== 
Project:                    Asterisk
Issue ID:                   14000
Category:                   Channels/chan_sip/CodecHandling
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     resolved
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 159896 
Disclaimer on File?:        N/A 
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2008-12-01 07:36 CST
Last Modified:              2008-12-02 11:42 CST
====================================================================== 
Summary:                    [patch] Wrong usage of sscanf with use of
uninitialized variable caused accidental parsing of RTP/SAVP
Description: 
Hi folks!

We are Nortel VoIP-PBX Supporter and have a customer with as SIP-Trunk
between Nortel CS1000 and Asterisk. Worked fine. After an upgrade on Nortel
PBX to a new MediaGatewayCard (MC32s) no calls could be established. The
Nortel offers after the upgrade next to RTP also SRTP. 

But asterisk accidentaly parses also the m=audio line with RTP/SAVP in the
incoming SDP-Message causing to refused the call ('488 Not acceptable').

It was because a sscanf is used in chan_sip.c / process_sdp() to compare
and examine the 'm=audio' in a wrong way. As soon as the line starts with
'audio ' followed by a number, sscanf returns '1' regardless of the rest of
the line. The result of '%n' variable of sscanf was then used unitialized.

With my fix now chan_sip ignores now the 'm=audio ... RTP/SAVP' lines and
everything is fine.

see details

patch available


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

---------------------------------------------------------------------- 
 (0095676) svnbot (reporter) - 2008-12-02 11:42
 http://bugs.digium.com/view.php?id=14000#c95676 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 160297

U   branches/1.4/channels/chan_sip.c

------------------------------------------------------------------------
r160297 | tilghman | 2008-12-02 11:42:04 -0600 (Tue, 02 Dec 2008) | 10
lines

When the text does not match exactly (e.g. RTP/SAVP), then the %n
conversion
fails, and the resulting integer is garbage.  Thus, we must initialize the
integer and check it afterwards for success.
(closes issue http://bugs.digium.com/view.php?id=14000)
 Reported by: folke
 Patches: 
       asterisk-sipbg-sscanf-1.4.22.diff uploaded by folke (license 626)
       asterisk-sipbg-sscanf-1.6.0.1.diff uploaded by folke (license 626)
       asterisk-sipbg-sscanf-trunk-r159896.diff uploaded by folke (license
626)

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

http://svn.digium.com/view/asterisk?view=rev&revision=160297 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-12-02 11:42 svnbot         Checkin                                      
2008-12-02 11:42 svnbot         Note Added: 0095676                          
2008-12-02 11:42 svnbot         Status                   assigned => resolved
2008-12-02 11:42 svnbot         Resolution               open => fixed       
======================================================================




More information about the asterisk-bugs mailing list