[asterisk-bugs] [JIRA] (ASTERISK-26586) chan_sip: Segfaults upon reload if client with MWI wasn't registered

[George Joseph (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-26586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

George Joseph updated ASTERISK-26586:
-------------------------------------

    Target Release Version/s: 13.14.0

> chan_sip: Segfaults upon reload if client with MWI wasn't registered
> --------------------------------------------------------------------
>
>                 Key: ASTERISK-26586
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26586
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/TCP-TLS
>    Affects Versions: 13.12.2
>         Environment: Debian 8 i686
>            Reporter: Michael Kuron
>      Target Release: 13.14.0
>
>         Attachments: bt1.txt, bt2.txt, btfull.txt, extensions.conf, logger.conf, modules.conf, sip.conf, voicemail.conf
>
>
> The following leads to a segfault in Asterisk 13. I have never observed this problem in Asterisk 11. However, judging from the backtrace, it is possible that ASTERISK-25747 is the same issue.
> # A client registers to Asterisk via TCP. Its IP address etc. get written to astdb at _/SIP/Registry/clientname_.
> At this point, {{sip show tcp}} shows an entry like {{192.168.200.144:61019 TCP Server}}.
> # I restart Asterisk or issue the commands {{module unload chan_sip}} and {{module load chan_sip}}.
> After this, {{sip show tcp}} will show a bogus entry like {{192.168.200.144:61019 TCP Client}} because, while loading the SIP configuration, Asterisk reads the client's last IP/port from astdb and attempts to send an MWI to it (see bt1.txt).
> If the client rejects that connection, everything is ok and the line disappears from {{sip show tcp}} again. However, if the client silently discards the connection (e.g. due to firewall settings), we have a problem in step 3b.
> # (a) If the client re-registers with Asterisk, the line in {{sip show tcp}} is replaced with a correct one like {{192.168.200.144:61020 TCP Server}}. (b) If, however, I run {{module unload chan_sip}} before the client re-registers, i.e. while {{192.168.200.144:61019 TCP Client}} is still there, Asterisk attempts to kill the TCP thread, which was never set up. This leads to a segfault (see bt2.txt).
> I have attached a minimal configuration that reproduces the issue. Note that not all clients trigger it. Snom phones, for example, reject the connection in step 2 and the problem doesn't occur. A Gigaset N510 on the other hand silently discards the connection, which triggers the problem. If you disconnect the client from the network before Asterisk tries to make the connection, you can probably trigger it with any client as the connection will never be accepted or rejected.



--
This message was sent by Atlassian JIRA
(v6.2#6252)