[Home]

Summary:ASTERISK-19941: Crash in res_config_ldap when used with realtime extensions
Reporter:Slava Bendersky (volga629)Labels:realtime
Date Opened:2012-06-01 19:10:30Date Closed:2017-02-17 12:35:05.000-0600
Priority:CriticalRegression?
Status:Closed/CompleteComponents:Resources/res_config_ldap
Versions:1.8.11.1 11.5.1 Frequency of
Occurrence
Related
Issues:
is the original version of this clone:ASTERISK-19977 CLONE - Asterisk res ldap
Environment:Asterisk Now 2.2 GUI and LDAP Imap voicemail registration Attachments:( 0) backtrace.txt
Description:Asterisk trying to modify entries in LDAP server DS 389.
Also when I got sip user registered and I trying place call it just silence, I don't see any attempts to dial in logs.

[2012-05-28 00:07:18] ERROR[25975]: res_config_ldap.c:1328 update_ldap: Couldn't modify 'name'='sbendersky', dn:uid=,ou=People,dc=,dc= because No such attribute
   -- Registered SIP 'sbendersky' at 10.16.130.45:32899
[2012-05-28 00:07:20] ERROR[26001]: res_config_ldap.c:1328 update_ldap: Couldn't modify 'name'='sbendersky', dn:uid=sbendersky,ou=People,dc=networklab,dc=ca because Object class violation
   -- Unregistered SIP 'sbendersky'
[2012-05-28 00:07:26] ERROR[26001]: res_config_ldap.c:1328 update_ldap: Couldn't modify 'name'='sbendersky', dn:uid=sbendersky,ou=People,dc=networklab,dc=ca because No such attribute


Extension conf

[users]
switch => Realtime/@

[voicemail]
switch => Realtime/@

[realtime-ldap]
include => users
include => voicemail

Extconfig conf

[settings]
sipusers => ldap,"ou=People,dc=networklab,dc=ca",sip
sippeers => ldap,"ou=People,dc=networklab,dc=ca",sip
extensions => ldap,"ou=NetLabExtensions,dc=networklab,dc=ca",extensions
voicemail => ldap,"ou=NetLabVoicemail,dc=networklab,dc=ca",voicemail
Comments:By: Rusty Newton (rnewton) 2012-06-04 13:51:07.870-0500

Thanks for your comments. This does not appear to be a bug report and we are closing it. We appreciate the difficulties you are facing, but it would make more sense to raise your question in one of the resources here http://www.asterisk.org/support.


I know you filed this as an Information Request, but I don't see any clear question. Rather this appears to be a "I'm seeing errors, tell me whats wrong" request, which is a support issue that someone in the community may be able to help you with.

By: Slava Bendersky (volga629) 2012-06-08 18:40:23.458-0500

This last crash from June 8 2012

By: Slava Bendersky (volga629) 2012-06-08 18:44:07.188-0500

The request information was because asterisk crash constantly. And no information available about LDAP integration. I am whole asking people in irc and forums about LDAP extensions and context integration with real time LDAP driver and nobody can point into right place. Please see attached backtrace.  

By: Matt Jordan (mjordan) 2012-06-19 07:55:03.910-0500

Thank you for attaching the backtrace for this issue.  Please note that both realtime extensions and res_config_ldap are extended support modules [1].  As such, development efforts for them come from the Asterisk Developer community, and response times may reflect that.

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Module+Support+States

By: Tzafrir Cohen (tzafrir) 2013-10-10 23:39:38.382-0500

Dominik George reported a similar issue to the Debian bug tracker:

http://bugs.debian.org/725925

A few lines from the trace:

#0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:31
#1  0x00007fffa72be5d1 in realtime_multi_ldap (basedn=<optimized out>, table_name=0x7fffc6043980 "sip", ap=0x7fffc6043868)
   at res_config_ldap.c:976
#2  0x0000000000488dfd in ast_load_realtime_multientry (family=family@entry=0x7fffa2c6002b "sippeers") at config.c:2677

strlen is part of the ast_strdupa macro called in realtime_multi_ldap(). It is called on a variable retrieved from the variable-args struct. But is aparantly corrupted.

However, the variable-args are retrieved in a previous call a few lines up to realtime_ldap_base_ap(). So I have no idea how that code should work.

By: Chris Ridd (cjr) 2014-04-01 09:58:37.257-0500

I think there's a problem with the va_list (ap) being passed down into the realtime_ldap_base_ap() function, which might mutate it. The following link, which references the C standard, suggests the results of doing this are indeterminate for the caller: https://www.securecoding.cert.org/confluence/display/seccode/MSC39-C.+Do+not+call+va_arg()+on+a+va_list+that+has+an+indeterminate+value

This patch fixes the problem on our servers:

\[Edit: mjordan\]

Removed inline patch.


By: Chris Ridd (cjr) 2014-06-03 10:26:28.650-0500

Is anyone able to verify the fix I proposed and commit it?

By: Matt Jordan (mjordan) 2014-06-03 11:03:29.308-0500

Patches cannot be accepted in-line. They must be attached to the issue in unified diff format after signing a license contributor agreement.

Once a patch is attached to this issue, you can submit it for code review on Review Board.

Please see https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process for more information.

By: Jeremy Lainé (sharky) 2014-08-07 04:44:57.163-0500

Any progress on fixing this bug?

By: Chris Ridd (cjr) 2014-08-07 05:46:21.525-0500

Looking at the trunk it would appear that the code was changed in r386731 to avoid this buggy behaviour:

{quote}
r386731 | file | 2013-04-27 13:01:29 +0100 (Sat, 27 Apr 2013) | 11 lines

Add support for a realtime sorcery module.

This change does the following:

1. Adds the sorcery realtime module
2. Adds unit tests for the sorcery realtime module
3. Changes the realtime core to use an ast_variable list instead of variadic arguments
4. Changes all realtime drivers to accept an ast_variable list

Review: https://reviewboard.asterisk.org/r/2424/
{quote}

That change is in the version 12 branch but not the version 11 branch.

By: Sean Bright (seanbright) 2017-02-16 14:36:51.632-0600

Can anyone confirm whether or not this is an issue in Asterisk 13? I am not able to reproduce this.

By: Sean Bright (seanbright) 2017-02-17 12:35:05.202-0600

As pointed out by Chris Ridd, the segfault you were seeing was most likely caused by using {{va_list}}s inappropriately, and that code was replaced in April 2013 in r386731.

If you experience this crash with Asterisk 13 or later, please feel free to re-open.