[Home]

Summary:ASTERISK-17591: [patch] Remote bridging of certain IPs causes segfault
Reporter:naomi (naomi)Labels:patch
Date Opened:2011-03-22 07:58:17Date Closed:2018-01-02 08:44:28.000-0600
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Core/Netsock
Versions:1.8.4 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) backtrace.txt
( 1) full
( 2) issue19009_no_bail_on_no_200_contact.patch
Description:When remotely bridging two SIP channels, Asterisk dies with a segfault.

I can reproduce this reliably (on about every second call) with one particular DDI and one particular outgoing SIP trunk, and never otherwise.

There seems to be a null pointer passed to ast_sockaddr_resolve in netsock.c when it happens.

I fear this may be a re-emergence of a bug that was mentioned in a Linux security tracker in 2007:

http://www.linuxsecurity.com/content/view/128447

****** ADDITIONAL INFORMATION ******

On calls that work, I can see the host and port being handled correctly

[2011-03-22 11:17:22] DEBUG[4490] chan_sip.c: Updating call counter for incoming call
[2011-03-22 11:17:22] DEBUG[4490] netsock2.c: Splitting '83.245.1.136:5061' gives...
[2011-03-22 11:17:22] DEBUG[4490] netsock2.c: ...host '83.245.1.136' and port '5061'.

But on ones that crash Asterisk we usually get this instead:

[2011-03-22 11:17:48] DEBUG[4490] chan_sip.c: Updating call counter for incoming call
[2011-03-22 11:17:48] WARNING[4490] chan_sip.c: Invalid contact uri  (missing sip: or sips:), attempting to use anyway

We do not always get the Invalid contact uri message, but I suspect that's because it sometimes crashes before it has time to output it.

I can see from the backtrace that at this point 0x0 is being passed into the str parameter for ast_sockaddr_resolve:

#1  0x00000000004f88dd in ast_sockaddr_resolve (addrs=0x7fb5dffb7770, str=0x0, flags=0, family=2) at netsock2.c:235

From the Asterisk docs I can see that str is a pointer to a string containing the host and port.

ast_sockaddr_resolve (struct ast_sockaddr **addrs, const char *str, int flags, int family)
Comments:By: naomi (naomi) 2011-03-22 08:07:42

The full log shows a call where I used realtime, however please don't be led astray by that as I have reproduced this reliably without realtime.
By: naomi (naomi) 2011-03-28 05:31:07

Since then I have discovered that the segfault occurs when an attempt to reinvite is taking place.

Setting reinvite to no gets rid of the problem. I still think this is a bug though, as setting reinvite to yes should not cause a segfault
By: naomi (naomi) 2011-03-28 05:32:31

The reason it looked like it was only happened with certain IPs is that those providers were trying to reinvite whereas others were not.
By: Walter Doekes (wdoekes) 2011-03-28 07:54:52

Try this patch. It ignores that a 200 OK has no Contact if pvt->sa is already set (has a non-zero port).


By: naomi (naomi) 2011-05-11 04:45:25

Thanks for your help. We used a workaround and the project has moved on without the patch getting tested. I still intend to recreate the problem on a test machine and give some feedback on the patch but since it may take a while to get round to this I just wanted to say thanks now and acknowledge it.
By: Joshua C. Colp (jcolp) 2017-12-19 07:01:00.782-0600

Is this still a problem under recent supported versions of Asterisk? Were you able to test the patch?
By: Asterisk Team (asteriskteam) 2018-01-02 08:44:28.607-0600

Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1].

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines