[asterisk-bugs] [Asterisk 0016904]: [patch] [regression] Duplicate TXREQ packets will cause chan_iax2 to reject an unrelated call in the future

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16904 
====================================================================== 
Reported By:                rain
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   16904
Category:                   Channels/chan_iax2
Reproducibility:            random
Severity:                   minor
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           1.6.2.2 
JIRA:                       SWP-967 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-02-25 11:32 CST
Last Modified:              2010-02-25 14:20 CST
====================================================================== 
Summary:                    [patch] [regression] Duplicate TXREQ packets will
cause chan_iax2 to reject an unrelated call in the future
Description: 
When Asterisk receives an IAX2 TXREQ packet, try_transfer() will call
store_by_transfercallno() to link the chan_iax2_pvt struct into
iax_transfercallno_pvts.  If a duplicate TXREQ packet is received for the
same call, the pvt struct will be linked into iax_transfercallno_pvts
multiple times.

Since store_by_transfercallno() is little more than a wrapper for
ao2_link(), it will dutifully add the chan_iax2_pvt struct to
iax_transfercallno_pvts each time it's called; however, the call will only
be unlinked once (in iax2_destroy() or complete_transfer().¹)  This
results in a memory leak (Asterisk sets the pointer in iaxs[] to NULL in
iax2_destroy() and will never unreference this chan_iax2_pvt again) and,
eventually, a rejected call.

After the call where the duplicate TXREQs were received ends, the
originating host may reuse the same call number.  When this call number
appears in a NEW packet, find_callno() will find the old chan_iax2_pvt in
iax_transfercallno_pvts and return its callno.  Since the iaxs[] entry for
this callno is NULL (the call was probably destroyed long ago),
socket_process() will summarily reject the new call with INVAL via
raw_hangup().

My fix (attached) is to only call store_by_transfercallno() if
pvt->transferring is TRANSFER_NONE immediately before ->transferring is set
to TRANSFER_BEGIN.  The structure will still be updated if the transferid
is changed in the duplicate TXREQ, so I don't believe this will cause any
issues.

I've been testing this patch for over 12 hours and haven't noticed any
issues yet.

¹ Actually, this is a lie, due to a trivial bug in complete_transfer():
pvt->transfercallno should be set to 0 when the transfer completes, not -1.
 A fix for this is also in the patch I've attached.

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

---------------------------------------------------------------------- 
 (0118570) rain (reporter) - 2010-02-25 14:20
 https://issues.asterisk.org/view.php?id=16904#c118570 
---------------------------------------------------------------------- 
Sure, these are all related to the fix for issue
https://issues.asterisk.org/view.php?id=13468:
1.4 - r173248
1.6.0 - r173250
1.6.1 - r173506 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-02-25 14:20 rain           Note Added: 0118570                          
======================================================================