Summary:ASTERISK-17939: [patch] used auth= parameter freed during sip reload => crash
Reporter:Walter Doekes (wdoekes)Labels:
Date Opened:2011-05-28 09:14:59Date Closed:2011-07-05 12:39:23
Versions:Frequency of
Environment:Attachments:( 0) issue19382_increase_likelyhood_of_crash_THIS_IS_NOT_A_FIX.patch
( 1) jira_asterisk_17939_v1.8.patch

if you use the auth= parameter and do a "sip reload" while there is an ongoing call. The peer->auth data points to free'd memory.

Affected versions: -trunk and -1.6.2.x and probably every other version that has the auth= parameter in sip.conf.

Because the memory is free'd before being re-allocated, in a test-setup there are chances that you get the same memory back and the crash doesn't occur. I've created a little patch that increases the likelyhood of getting a crash, so you can confirm the problem more easily.

(And before you complain that I'm writing to free'd memory in that patch: that's to overcome any 0-setting of auth->next by ast_free. The kernel still thinks it's my memory and won't segfault over that.)

****** STEPS TO REPRODUCE ******



Open a CLI:

*CLI> channel originate SIP/trunk/<somenumber> application Answer 20

In the mean time, in another CLI:

*CLI> sip reload


0x00007ffff74feb24 in strcasecmp () from /lib/libc.so.6
(gdb) back
#0  0x00007ffff74feb24 in strcasecmp () from /lib/libc.so.6
#1  0x00007fffebaec150 in find_realm_authentication (authlist=0xe0b088, realm=0xe3d209 "itsp.tld") at chan_sip.c:26352
#2  0x00007fffebac7f6a in build_reply_digest (p=0xe397d0, method=8, digest=0x7fffd82ba630 "", digest_len=1024) at chan_sip.c:18863
#3  0x00007fffebaa7b7a in transmit_request_with_auth (p=0xe397d0, sipmethod=8, seqno=0, reliable=XMIT_RELIABLE, newbranch=1) at chan_sip.c:13336
#4  0x00007fffeba83cab in sip_hangup (ast=0xe52cd0) at chan_sip.c:6253
ASTERISK-1  0x000000000047671e in ast_hangup (chan=0xe52cd0) at channel.c:2849
ASTERISK-2  0x000000000052a847 in async_wait (data=0xe37f18) at pbx.c:8514
ASTERISK-3  0x000000000057a097 in dummy_start (data=0xe571a8) at utils.c:1010
ASTERISK-4  0x00007ffff6d0d9ca in start_thread () from /lib/libpthread.so.0
ASTERISK-5  0x00007ffff755e70d in clone () from /lib/libc.so.6
ASTERISK-6 0x0000000000000000 in ?? ()
(gdb) up
#1  0x00007fffebaec150 in find_realm_authentication (authlist=0xe0b088, realm=0xe3d209 "itsp.tld") at chan_sip.c:26352
26352 if (!strcasecmp(a->realm, realm))
(gdb) print a
$1 = (struct sip_auth *) 0xdeadbeef


As you can see, the problem is that peer->auth of an ongoing call is pointing to old auth= settings that have been free'd already.

I don't have a quick-fix here. A ref-counter on the peer->auth value sounds like overkill. But you probably have a clever idea about how to fix this.

Observe that the fact that I need a patch to get 100%-reproducible behaviour does not mean that it is a theoretical problem. This issue killed our production asterisken a couple of times yesterday.

Walter Doekes
Comments:By: Richard Mudgett (rmudgett) 2011-06-30 16:14:05.855-0500

[^jira_asterisk_17939_v1.8.patch] should take care of the crash.  Minimal testing.

By: Richard Mudgett (rmudgett) 2011-07-05 12:37:01.025-0500

Committed trunk -r326321.

Merged revisions 326291 via svnmerge from

 r326291 | rmudgett | 2011-07-05 12:22:59 -0500 (Tue, 05 Jul 2011) | 23 lines

 Used auth= parameter freed during "sip reload" causes crash.

 If you use the auth= parameter and do a "sip reload" while there is an
 ongoing call.  The peer->auth data points to free'd memory.

 The patch does several things:

 1) Puts the authentication list into an ao2 object for reference counting
 to fix the reported crash during a SIP reload.

 2) Converts the authentication list from open coding to AST list macros.

 3) Adds display of the global authentication list in "sip show settings".

 (closes issue ASTERISK-17939)
 Reported by: wdoekes
       jira_asterisk_17939_v1.8.patch (license #5621) patch uploaded by rmudgett

 Review: https://reviewboard.asterisk.org/r/1303/

 JIRA SWP-3526