[asterisk-bugs] [JIRA] (ASTERISK-20929) Core-dump on SIP BYE for an invalid call transaction

[Mark Michelson (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-20929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=202200#comment-202200 ] 

Mark Michelson commented on ASTERISK-20929:
-------------------------------------------

The operation that is causing problems is the transfer using the INVITE with replaces. For brevity's sake, we'll refer to the dialogs here as dialog A and dialog B. In actuality, Dialog A has call-ID MTE3NDcwNzFjYjA1MDcxODQzMGQ2MmEyMDE1MDVhNDI. and Dialog B has call-ID NmM0MjQwOGJlOGFjZjY5MjJhZDc0N2NkZDY2N2QxM2Y.

Dialog A is an incoming call to Asterisk that gets set up with no issues. This includes reinvites to get direct media between Dialog A's endpoint and whoever he is connected to.

Dialog B sends an INVITE with Replaces in order to take the place of Dialog A in the conversation he's having. This causes Asterisk to set up a channel masquerade to place Dialog B's channel information into Dialog A's channel.

Later a BYE arrives on Dialog A and this causes the crash to occur, because it appears as though the owner channel on the dialog has been killed. Presumably, we're accessing freed memory here. You can see in the log the line:

{noformat}
[Jan 13 21:14:13] DEBUG[31759][C-00000000] chan_sip.c: SIP Fixup: New owner for dialogue MTE3NDcwNzFjYjA1MDcxODQzMGQ2MmEyMDE1MDVhNDI.: SIP/pre-3cx-tst-00000000<ZOMBIE> (Old parent: SIP/pre-3cx-tst-00000002)
{noformat}

This means that Dialog A is now pointing at a zombie channel that is about to be freed. The problem though is that the dialog is still alive after this point, so the BYE isn't rejected with a 481. Instead, the BYE is accepted, the channel is accessed, and that causes a meltdown.

I'm going to use your pcap to build a couple of SIPp scenarios that should allow for me to reproduce the scenario. I'll run with some debugging tools and see if I can figure out what the problem is.
                
> Core-dump on SIP BYE for an invalid call transaction
> ----------------------------------------------------
>
>                 Key: ASTERISK-20929
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20929
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General
>    Affects Versions: 11.1.0, 11.1.1, 11.1.2
>         Environment: Linux/2.6.32-279.19.1.el6.i686 #1 SMP Wed Dec 19 04:30:58 UTC 2012 i686 i686 i386 GNU/Linux
>            Reporter: Kristopher Lalletti
>            Assignee: Matt Jordan
>         Attachments: ast.core.31716.txt, ast.log.full.txt, ast.log.mmlog.txt, core-20130111-01.txt, sip.proto.pcap.txt
>
>
> We've been noticing core-dumps on Asterisk since we migrated from 1.8.x to 11.1.x late last December, which caused us to rollback to 1.8.19.1 in order to return into a stable state.
> We noticed a very specific (mis)behaviour of our soft-switch to which when it signaled a SIP BYE message to ASterisk with an invalid Call-ID, Asterisk would systematically segfault. 
> When we backtracked to 1.8.19.1, at least Asterisk will return a "481 Call leg/transaction does not exist" and not die.
> Included is the core-dump backtrace showing the SIP BYE transaction causing Asterisk 11.1.1 to segfault.  
> PS: I also have a system running 11.1.2 which is equally having the same symptoms, but I have yet to capture a tangible backtrace.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira