[asterisk-bugs] [JIRA] (ASTERISK-26586) sip reload segfaults if client with MWI was registered previously but wasn't registered before reload

[Michael Kuron (JIRA)]

Michael Kuron created ASTERISK-26586:
----------------------------------------

             Summary: sip reload segfaults if client with MWI was registered previously but wasn't registered before reload
                 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
         Attachments: 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)