[Home]

Summary:ASTERISK-06478: ENUMLOOKUP crashes * with specific enums
Reporter:Tony Plack (plack)Labels:
Date Opened:2006-03-05 11:13:39.000-0600Date Closed:2006-05-19 10:54:00
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Applications/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) core.24710.gz
( 1) enum.conf
( 2) enum-crash-console-output.txt
Description:implementing e164.org on asterisk, I tried some of their "test" numbers and I am able to make * crash consistantly.

the dialplan function is
exten => s,n,Set(count=${ENUMLOOKUP(+${ARG1},ALL,c,e164.org)}|counter=0)

ARG1 being passed is 16049586111 which will crash the system.  This should return the following entries:
h323:9586111@mutual.bcwireless.net
ADDRESS:CN=Automated Number Announcement;O=British Columbia Wireless Network Society;OU=VoIP Guys;STREET=2465 Beta Avenue - Suite 108;L=Burnaby;ST=BC;C=Canada;PC=V5C 5N1ADDRESS:CN=Automated Number Announcement;O=British Columbia Wireless Network Society;OU=VoIP Guys;STREET=2465 Beta Avenue - Suite 108;L=Burnaby;ST=BC;C=Canada;PC=V5C 5N1
AAA:AAA://auth.bcwireless.net:1813;transport=udp;protocol=radiusAAA:AAA://auth.bcwireless.net:1813;transport=udp;protocol=radius
sip:9586111@mutual.bcwireless.net

But instead crashes the system.

Removing e164.org from the dialplan ( and defaulting to enum.conf) returns nothing.  I mean nothing ever for any number.

16049580001 returns the correct entries (with e164.org in the function call) and does not crash the system.

The system ends as follows:
   -- Executing NoOp("SIP/GT488-1-deb9", "") in new stack
   -- Executing Macro("SIP/GT488-1-deb9", "enum-call|16049586111") in new stack
   -- Executing NoOp("SIP/GT488-1-deb9", "Lookup 16049586111 in enum") in new stack
Ouch ... error while writing audio data: : Broken pipe
Junk at the beginning 49443303
Warning, flexibel rate not heavily tested!
Segmentation fault (core dumped)

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

BT produces the following:

#0  0x40150fcc in memcpy () from /lib/tls/libc.so.6
(gdb) bt
#0  0x40150fcc in memcpy () from /lib/tls/libc.so.6
#1  0x080ca944 in enum_callback (context=0x0, answer=0x0, len=0,
   fullanswer=0x0) at enum.c:96
#2  0x00000000 in ?? ()
Comments:By: Tony Plack (plack) 2006-03-05 11:20:52.000-0600

Here is the macro I am calling in the dialplan:

[macro-enum-call]
exten => s,1,Noop(Lookup ${ARG1} in enum)
exten => s,n,Set(count=${ENUMLOOKUP(+${ARG1},ALL,c,e164.org)}|counter=0)
exten => s,n(start),GotoIf($["${counter}" >= "${count}"]?macro-enum-call,s,end)
exten => s,n,Set(counter=$[${counter}+1])
exten => s,n,Set(ENUM=${ENUMLOOKUP(+${ARG1},ALL,${counter},e164.org)})
exten => s,n,GotoIf($["${LEN(${ENUM})}" = "0" ]?macro-enum-call,s,continue)
exten => s,n,GotoIf($["${ENUM:0:3}" = "sip" ]?macro-enum-call,s,sipuri)
exten => s,n,GotoIf($["${ENUM:0:3}" != "iax" ]?macro-enum-call,s,continue)
exten => s,n,Set(DIALSTR=IAX2/${ENUM:5})
exten => s,n,Goto(macro-enum-call,s,dodial)
exten => s,n(sipuri),Noop
exten => s,n,Set(DIALSTR=SIP/${ENUM:4})
exten => s,n(dodial),Noop
exten => s,n,Noop(Trying ${ENUM})
exten => s,n,SetAccount(enum)
exten => s,n,Dial(${DIALSTR}|120)
exten => s,n,GotoIf($[$["${DIALSTATUS}"="CHANUNAVAIL"]| $["${DIALSTATUS}"="CONGESTION"]]?macro-enum-call,s,continue:macro-enum-call,s,hangup)
exten => s,n(continue),Goto(macro-enum-call,s,start)
exten => s,n(hangup),Noop
exten => s,n,NoOp(Enum Dial failed due to ${DIALSTATUS})
exten => s,n,Hangup
exten => s,n(end),Noop
By: Tony Plack (plack) 2006-03-05 12:46:38.000-0600

I have added some messages to enum.c and finally turned on debug. Here is what I have at this point, I am going to keep backtracing in the code to work out when exactly the error occurs.  I am working off the assumption that the code failure is in parse_ie() in ./enum.c.  As I assume this is from function parse_naptr(), I am tracing it back from here.   The messages at 132, 141, 150 are my own insertions into the code to help determine which function call is causing the issue.

Mar  5 13:35:29 DEBUG[368]: enum.c:165 parse_naptr: NAPTR input='+16049586111', flags='u', services='E2U+SIP', regexp='!^\+16049586111$!sip:9586111@mutual.bcwireless.net!', repl=''
Mar  5 13:35:29 DEBUG[368]: enum.c:132 parse_naptr: Retrieving flags from NAPTR record
Mar  5 13:35:29 DEBUG[368]: enum.c:141 parse_naptr: Retrieving services from NAPTR record
Mar  5 13:35:29 DEBUG[368]: enum.c:150 parse_naptr: Retrieving regexp from NAPTR record
Mar  5 13:35:29 DEBUG[368]: enum.c:165 parse_naptr: NAPTR input='+16049586111', flags='u', services='E2U+H323', regexp='!^\+16049586111$!h323:9586111@mutual.bcwireless.net!', repl=''
Mar  5 13:35:29 DEBUG[368]: enum.c:132 parse_naptr: Retrieving flags from NAPTR record
Mar  5 13:35:29 DEBUG[368]: enum.c:141 parse_naptr: Retrieving services from NAPTR record
Mar  5 13:35:29 DEBUG[368]: enum.c:150 parse_naptr: Retrieving regexp from NAPTR record
Ouch ... error while writing audio data: : Broken pipe
Junk at the beginning 49443303
Warning, flexibel rate not heavily tested!
Segmentation fault (core dumped)
By: Tony Plack (plack) 2006-03-05 13:50:16.000-0600

The node it is trying to parse when it fails is the ADDRESS record.  It is not making it through the regexp call to parse_ie() in enum.c:

Mar  5 14:36:10 DEBUG[10298]: enum.c:133 parse_naptr: NAPTR input='u
                                                                   E2U+ADDRESS®!.*!ADDRESS:CN=Automated Number Announcement;O=British Columbia Wireless Network Society;OU=VoIP Guys;STREET=2465 Beta Avenue - Suite 108;L=Burnaby;ST=BC;C=Canada;PC=V5C 5N1!'
Mar  5 14:36:10 DEBUG[10298]: enum.c:137 parse_naptr: Retrieving flags from NAPTR record
Mar  5 14:36:10 DEBUG[10298]: enum.c:146 parse_naptr: Retrieving services from NAPTR record
Mar  5 14:36:10 DEBUG[10298]: enum.c:155 parse_naptr: Retrieving regexp from NAPTR record
Ouch ... error while writing audio data: : Broken pipe
Junk at the beginning 49443303
Warning, flexibel rate not heavily tested!
Segmentation fault (core dumped)
By: Tony Plack (plack) 2006-03-05 14:27:32.000-0600

Well it looks like the memcpy logic is not correct and the char arrays are not lineing up.  After removing most of my entries and making some new ones, I have discovered that the result is not consistant in the code.  We are ending up with a negative buffer length.  My ast_log line is just before:

if (len > maxdatalen)
len = maxdatalen;
memcpy(data, src, len);

in parse_ie().

The answer= is just before we call parse_ie() for regexp so that I can see what "answer" it is sending to the function.

Here is the latest debug:

   -- Executing NoOp("SIP/GT488-1-b05f", "Lookup 16049586111 in enum") in new stack
Mar  5 15:24:23 DEBUG[17707]: app_queue.c:471 changethread: Device 'SIP/GT488-1' changed to state '2' (In use)
Mar  5 15:24:24 DEBUG[17706]: enum.c:95 parse_ie: len=1, srclen=189, maxdatalen=511
Mar  5 15:24:24 DEBUG[17706]: enum.c:95 parse_ie: len=11, srclen=187, maxdatalen=511
Mar  5 15:24:24 DEBUG[17706]: enum.c:150 parse_naptr: NAPTR answer='®!.*!ADDRESS:CN=Automated Number Announcement;O=British Columbia Wireless Network Society;OU=VoIP Guys;STREET=2465 Beta Avenue - Suite 108;L=Burnaby;ST=BC;C=Canada;PC=V5C 5N1!', len='176'
Mar  5 15:24:24 DEBUG[17706]: enum.c:95 parse_ie: len=-82, srclen=175, maxdatalen=511
Ouch ... error while writing audio data: : Broken pipe
Junk at the beginning 49443303
Warning, flexibel rate not heavily tested!
Segmentation fault (core dumped)
By: Tony Plack (plack) 2006-03-05 16:27:50.000-0600

Well a temporary solution to the problem can be had by inserting the following in parse_ie:

if (len < 0) {
ast_log(LOG_WARNING, "len was %d and less than 0.  Setting it to srclen %d\n", len, srclen);
len = srclen;
} else {
src++;
srclen--;
}

in place of

src++;
srclen--;

The answer line we are putting into parse_naptr() is

Mar  5 16:45:29 DEBUG[27692]: enum.c:139 parse_naptr: NAPTR answer='u
                                                                    E2U+ADDRESS®!.*!ADDRESS:CN=Automated Number Announcement;O=British Columbia Wireless Network Society;OU=VoIP Guys;STREET=2465 Beta Avenue - Suite 108;L=Burnaby;ST=BC;C=Canada;PC=V5C 5N1!'

Not sure if this is a upstream error or results from e164.org.  One thing for sure, we should have better length verification in this area.

It could be a bug in ast_search_dns() since this is the function providing the callback and the "answer" which is in error.  Not sure how deep we should search for this.

Other records that have the ADDRESS enum type seem to work okay, not sure why this one is faulty.
By: Tony Plack (plack) 2006-03-06 16:05:55.000-0600

Disclaimer faxed
By: Olle Johansson (oej) 2006-04-04 15:10:08

I can repeat this.
By: Olle Johansson (oej) 2006-04-04 15:46:24

Seems to be something weird with the string we are getting
By: Olle Johansson (oej) 2006-04-04 15:58:39

It's the E2U+ADDRESS record that causes the problem. Must have something to do with the length of the record.
By: Olle Johansson (oej) 2006-04-05 01:23:51

Are you sure that the E2U+ADDRESS record is correct? Seems to be a weird value between the label "E2U+ADDRESS" and the exclamation mark... We should not crash on that, but I wonder if it's valid at all or should the record be discarded?
By: Olle Johansson (oej) 2006-04-05 01:52:09

Added a control for len<0 in enum.c svn 1.2 rev 17489 and svn trunk.

Still would like to find out what the problem is with this record, so we can parse it properly, if it's correct.
By: Olle Johansson (oej) 2006-04-14 01:16:21

According to evilbuny, there's something fishy in the parsing of the record.
By: Mark Spencer (markster) 2006-05-11 03:28:20

Fixed in SVN trunk, thanks!
By: Serge Vecher (serge-v) 2006-05-11 09:16:03

does this need a backport to 1.2?
By: Joshua C. Colp (jcolp) 2006-05-19 10:53:59

Fix is now also in 1.2, this concludes our ENUMLOOKUP crashing bug.