(ITS#7144) reproducible segfault on slave/consumer during sync-replication
by sven＠svenhartge.de
Full_Name: Sven Hartge
Version: 2.4.28
OS: Debian Squeeze
URL:
Submission from: (NULL) (2a01:198:329:1::14)
I experience an easy to reproduce and consistent segfault when I setup a slapd
syncrepl consumer on Squeeze.
This segfault always happens during the replication of the same object, but the
slapd version in Lenny has no problems with same DIT.
My oldstable replicas currently run a self-backported version of
2.4.21-1~dvz50+1, but both 2.4.17-2.1~bpo50+1 and 2.4.11-1+lenny2.1 are also
fine.
2.4.23-7.2 shows the segfault as all versions up to 2.4.28-1.1 do. Even if I
disable all indices and strip my configuration to the bare minimum needed (i.e.
self-defined objectclasses and attributes) I get the segfault.
I also did da -O0 rebuild of the Debian-2.4.28 and this also segfaults in the
same way as 2.4.23 did. I have yet to test the latest RelEng24 from GIT, but I
wanted to submit this issue so someone may have a look at the backtrace in
parallel to my further tests.
I am aware the problem my lie in my self-defined objectclasses and attributes,
but then slapd should throw an error and exit instead of replicating 1/3 of the
DIT and then segfault.
I get a very good backtrace, but since this backtrace contains internal
information I am a bit hesitant to attach this backtrace to a public bug-report.
Is there a way to privatly submit this data (backtrace and additional schemas)
so you can have look at the problem?
11 years, 4 months
Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
by hyc＠symas.com
mattias(a)centaurix.com wrote:
> On Tue, 31 Jan 2012 03:56:06 +0100, Howard Chu<hyc(a)symas.com> wrote:
>
>> Mattias Andersson wrote:
>>> On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc(a)symas.com> wrote:
>>>
>>>> Please provide a full gdb backtrace from the assertion failure. I've
>>>> reproduced this configuration locally but see no crash using
>>>> ldapsearch.
>>>> I don't have the Softerra browser.
>>>
>>> Ok, see attachment. The problem is not reproducible with ldapsearch.
>>
>> Please see if the attached patch alters the behavior. Thanks.
>
> I'm getting an error that MozNSS is not found when I run ./configure.
Are you building the latest source? You can use --with-tls=openssl (or gnutls)
to explicitly choose. But it shouldn't be defaulting to MozNSS, unless perhaps
you're on a Redhat or Fedora system. If worse comes to worse, you can
configure --without-tls just to run this test.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
11 years, 4 months
Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
by mattias＠centaurix.com
On Tue, 31 Jan 2012 03:56:06 +0100, Howard Chu <hyc(a)symas.com> wrote:
> Mattias Andersson wrote:
>> On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc(a)symas.com> wrote:
>>
>>> Please provide a full gdb backtrace from the assertion failure. I've
>>> reproduced this configuration locally but see no crash using
>>> ldapsearch.
>>> I don't have the Softerra browser.
>>
>> Ok, see attachment. The problem is not reproducible with ldapsearch.
>
> Please see if the attached patch alters the behavior. Thanks.
I'm getting an error that MozNSS is not found when I run ./configure.
Mattias
11 years, 4 months
Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
by hyc＠symas.com
This is a multi-part message in MIME format.
--------------090902020105000306040907
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Mattias Andersson wrote:
> On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc(a)symas.com> wrote:
>
>> mattias(a)centaurix.com wrote:
>>> Full_Name: Mattias Andersson
>>> Version: 2.4.25
>>> OS: Linux
>>> URL: ftp://ftp.openldap.org/incoming/
>>> Submission from: (NULL) (83.182.107.220)
>>
>> Please provide a full gdb backtrace from the assertion failure. I've
>> reproduced this configuration locally but see no crash using ldapsearch.
>> I don't have the Softerra browser.
>
> Ok, see attachment. The problem is not reproducible with ldapsearch.
Please see if the attached patch alters the behavior. Thanks.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--------------090902020105000306040907
Content-Type: text/plain; charset=UTF-8;
name="diff.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="diff.txt"
diff --git a/servers/slapd/overlays/rwm.c b/servers/slapd/overlays/rwm.c
index 05cf98a..37e52cb 100644
--- a/servers/slapd/overlays/rwm.c
+++ b/servers/slapd/overlays/rwm.c
@@ -1277,7 +1277,7 @@ rwm_attrs( Operation *op, SlapReply *rs, Attribute** a_first, int stripEntryDN )
NULL );
if ( rc != LDAP_SUCCESS ) {
- BER_BVZERO( &(*ap)->a_nvals[i] );
+ ber_dupbv( &(*ap)->a_nvals[i], &(*ap)->a_vals[i] );
}
}
BER_BVZERO( &(*ap)->a_nvals[i] );
--------------090902020105000306040907--
11 years, 4 months
Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
by hyc＠symas.com
Mattias Andersson wrote:
> On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc(a)symas.com> wrote:
>
>> mattias(a)centaurix.com wrote:
>>> Full_Name: Mattias Andersson
>>> Version: 2.4.25
>>> OS: Linux
>>> URL: ftp://ftp.openldap.org/incoming/
>>> Submission from: (NULL) (83.182.107.220)
>>
>> Please provide a full gdb backtrace from the assertion failure. I've
>> reproduced this configuration locally but see no crash using ldapsearch.
>> I don't have the Softerra browser.
>
> Ok, see attachment. The problem is not reproducible with ldapsearch.
The assertion leads me to believe that one of the values received from the
remote server violated the attribute syntax, and so the value failed in the
normalizer on the local slapd. What is the remote server?
It's a bit strange that changing the configuration, but leaving the remote
server unchanged, avoids the problem.
> In any case, I have a different configuration now, that solves the problem
> in another way (by using two separate local databases -- one for the
> translucent overlay and one for the subordinate directory.) Another
> problem with the previous configuration was that I was getting "user
> modification of overlay database not permitted" errors when using
> ldapadd/ldapmodify (seems the translucent overlay can not be stacked with
> the rwm overlay.)
>
> Mattias
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
11 years, 4 months
Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
by mattias＠centaurix.com
------------hvfQvbIMuXxQGZ2Ols8tGf
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu <hyc(a)symas.com> wrote:
> mattias(a)centaurix.com wrote:
>> Full_Name: Mattias Andersson
>> Version: 2.4.25
>> OS: Linux
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (83.182.107.220)
>
> Please provide a full gdb backtrace from the assertion failure. I've
> reproduced this configuration locally but see no crash using ldapsearch.
> I don't have the Softerra browser.
Ok, see attachment. The problem is not reproducible with ldapsearch.
>> This is a security vulnerability, since it would be enough to send an
>> LDAP query
>> to take down the server.
>
> We don't consider crashes/DOS to be a security vulnerability. A
> vulnerability is anything which allows users to see information they
> should not be allowed to see; in the case of a crash no information can
> be retrieved so all data is completely secure.
You're right, but it's a service vulnerability -- the server must be
online in order for our users to be able to log in.
In any case, I have a different configuration now, that solves the problem
in another way (by using two separate local databases -- one for the
translucent overlay and one for the subordinate directory.) Another
problem with the previous configuration was that I was getting "user
modification of overlay database not permitted" errors when using
ldapadd/ldapmodify (seems the translucent overlay can not be stacked with
the rwm overlay.)
Mattias
------------hvfQvbIMuXxQGZ2Ols8tGf
Content-Disposition: attachment; filename=gdb-slapd.txt
Content-Type: text/plain; name="gdb-slapd.txt"
Content-Transfer-Encoding: Quoted-Printable
GNU gdb (Ubuntu/Linaro 7.3-0ubuntu2) 7.3-2011.08
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.=
html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copyin=
g"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>.
(gdb) handle SIG33 pass nostop noprint
Signal Stop Print Pass to program Description
SIG33 No No Yes Real-time event 33
(gdb) set pagination 0
(gdb) attach 4625
Attaching to process 4625
ptrace: No such process.
(gdb) attach 4824
Attaching to process 4824
ptrace: No such process.
(gdb) attach 4864
Attaching to process 4864
Reading symbols from /usr/sbin/slapd...Reading symbols from /usr/lib/deb=
ug/usr/sbin/slapd...done.
done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2...(no =
debugging symbols found)...done.
Loaded symbols for /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
Reading symbols from /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2...(no de=
bugging symbols found)...done.
Loaded symbols for /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2
Reading symbols from /usr/lib/libslp.so.1...(no debugging symbols found)=
...done.
Loaded symbols for /usr/lib/libslp.so.1
Reading symbols from /usr/lib/x86_64-linux-gnu/libsasl2.so.2...(no debug=
ging symbols found)...done.
Loaded symbols for /usr/lib/x86_64-linux-gnu/libsasl2.so.2
Reading symbols from /lib/x86_64-linux-gnu/libcrypt.so.1...(no debugging=
symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libcrypt.so.1
Reading symbols from /usr/lib/libltdl.so.7...(no debugging symbols found=
)...done.
Loaded symbols for /usr/lib/libltdl.so.7
Reading symbols from /lib/x86_64-linux-gnu/libwrap.so.0...(no debugging =
symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libwrap.so.0
Reading symbols from /lib/x86_64-linux-gnu/libpthread.so.0...(no debuggi=
ng symbols found)...done.
[Thread debugging using libthread_db enabled]
[New Thread 0x7f66e2c7d700 (LWP 4865)]
Loaded symbols for /lib/x86_64-linux-gnu/libpthread.so.0
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...(no debugging sym=
bols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libc.so.6
Reading symbols from /lib/x86_64-linux-gnu/libresolv.so.2...(no debuggin=
g symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libresolv.so.2
Reading symbols from /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2...(no=
debugging symbols found)...done.
Loaded symbols for /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2
Reading symbols from /usr/lib/x86_64-linux-gnu/libgnutls.so.26...(no deb=
ugging symbols found)...done.
Loaded symbols for /usr/lib/x86_64-linux-gnu/libgnutls.so.26
Reading symbols from /lib/x86_64-linux-gnu/libgcrypt.so.11...(no debuggi=
ng symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libgcrypt.so.11
Reading symbols from /lib/x86_64-linux-gnu/libnsl.so.1...(no debugging s=
ymbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libnsl.so.1
Reading symbols from /lib/x86_64-linux-gnu/libdl.so.2...(no debugging sy=
mbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libdl.so.2
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols=
found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /usr/lib/x86_64-linux-gnu/libkrb5.so.3...(no debugg=
ing symbols found)...done.
Loaded symbols for /usr/lib/x86_64-linux-gnu/libkrb5.so.3
Reading symbols from /usr/lib/x86_64-linux-gnu/libk5crypto.so.3...(no de=
bugging symbols found)...done.
Loaded symbols for /usr/lib/x86_64-linux-gnu/libk5crypto.so.3
Reading symbols from /lib/x86_64-linux-gnu/libcom_err.so.2...(no debuggi=
ng symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libcom_err.so.2
Reading symbols from /usr/lib/x86_64-linux-gnu/libkrb5support.so.0...(no=
debugging symbols found)...done.
Loaded symbols for /usr/lib/x86_64-linux-gnu/libkrb5support.so.0
Reading symbols from /usr/lib/x86_64-linux-gnu/libtasn1.so.3...(no debug=
ging symbols found)...done.
Loaded symbols for /usr/lib/x86_64-linux-gnu/libtasn1.so.3
Reading symbols from /lib/x86_64-linux-gnu/libz.so.1...(no debugging sym=
bols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libz.so.1
Reading symbols from /lib/x86_64-linux-gnu/libgpg-error.so.0...(no debug=
ging symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libgpg-error.so.0
Reading symbols from /lib/x86_64-linux-gnu/libkeyutils.so.1...(no debugg=
ing symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libkeyutils.so.1
Reading symbols from /lib/x86_64-linux-gnu/libnss_files.so.2...(no debug=
ging symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libnss_files.so.2
Reading symbols from /lib/libnss_mdns4_minimal.so.2...(no debugging symb=
ols found)...done.
Loaded symbols for /lib/libnss_mdns4_minimal.so.2
Reading symbols from /lib/x86_64-linux-gnu/libnss_dns.so.2...(no debuggi=
ng symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libnss_dns.so.2
Reading symbols from /usr/lib/x86_64-linux-gnu/sasl2/liblogin.so...(no d=
ebugging symbols found)...done.
Loaded symbols for /usr/lib/x86_64-linux-gnu/sasl2/liblogin.so
Reading symbols from /usr/lib/x86_64-linux-gnu/sasl2/libanonymous.so...(=
no debugging symbols found)...done.
Loaded symbols for /usr/lib/x86_64-linux-gnu/sasl2/libanonymous.so
Reading symbols from /usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so...(=
no debugging symbols found)...done.
Loaded symbols for /usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so
Reading symbols from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0...(no debu=
gging symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
Reading symbols from /usr/lib/x86_64-linux-gnu/sasl2/libcrammd5.so...(no=
debugging symbols found)...done.
Loaded symbols for /usr/lib/x86_64-linux-gnu/sasl2/libcrammd5.so
Reading symbols from /usr/lib/x86_64-linux-gnu/sasl2/libntlm.so...(no de=
bugging symbols found)...done.
Loaded symbols for /usr/lib/x86_64-linux-gnu/sasl2/libntlm.so
Reading symbols from /usr/lib/x86_64-linux-gnu/sasl2/libsasldb.so...(no =
debugging symbols found)...done.
Loaded symbols for /usr/lib/x86_64-linux-gnu/sasl2/libsasldb.so
Reading symbols from /usr/lib/x86_64-linux-gnu/libdb-5.1.so...(no debugg=
ing symbols found)...done.
Loaded symbols for /usr/lib/x86_64-linux-gnu/libdb-5.1.so
Reading symbols from /usr/lib/x86_64-linux-gnu/sasl2/libplain.so...(no d=
ebugging symbols found)...done.
Loaded symbols for /usr/lib/x86_64-linux-gnu/sasl2/libplain.so
Reading symbols from /usr/lib/ldap/back_hdb-2.4.so.2...Reading symbols f=
rom /usr/lib/debug/usr/lib/ldap/back_hdb-2.4.so.2.7.0...done.
done.
Loaded symbols for /usr/lib/ldap/back_hdb-2.4.so.2
Reading symbols from /usr/lib/x86_64-linux-gnu/libdb-4.8.so...(no debugg=
ing symbols found)...done.
Loaded symbols for /usr/lib/x86_64-linux-gnu/libdb-4.8.so
Reading symbols from /usr/lib/ldap/back_ldap-2.4.so.2...Reading symbols =
from /usr/lib/debug/usr/lib/ldap/back_ldap-2.4.so.2.7.0...done.
done.
Loaded symbols for /usr/lib/ldap/back_ldap-2.4.so.2
Reading symbols from /usr/lib/ldap/back_relay-2.4.so.2...Reading symbols=
from /usr/lib/debug/usr/lib/ldap/back_relay-2.4.so.2.7.0...done.
done.
Loaded symbols for /usr/lib/ldap/back_relay-2.4.so.2
Reading symbols from /usr/lib/ldap/translucent-2.4.so.2...Reading symbol=
s from /usr/lib/debug/usr/lib/ldap/translucent-2.4.so.2.7.0...done.
done.
Loaded symbols for /usr/lib/ldap/translucent-2.4.so.2
Reading symbols from /usr/lib/ldap/rwm-2.4.so.2...Reading symbols from /=
usr/lib/debug/usr/lib/ldap/rwm-2.4.so.2.7.0...done.
done.
Loaded symbols for /usr/lib/ldap/rwm-2.4.so.2
0x00007f66e7fa61f8 in pthread_join () from /lib/x86_64-linux-gnu/libpthr=
ead.so.0
(gdb) continue
Continuing.
[New Thread 0x7f66e247c700 (LWP 4874)]
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7f66e247c700 (LWP 4874)]
0x00007f66e7c343a5 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) backtrace full
#0 0x00007f66e7c343a5 in raise () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1 0x00007f66e7c37b0b in abort () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#2 0x00007f66e7c2cd4d in __assert_fail () from /lib/x86_64-linux-gnu/li=
bc.so.6
No symbol table info available.
#3 0x00007f66e92f8293 in attr_dup2 (tmp=3D0x7f66e9a40db8, a=3D0x7f66e9a=
40e80) at /build/buildd/openldap-2.4.25/servers/slapd/attr.c:236
i =3D <optimized out>
j =3D <optimized out>
__PRETTY_FUNCTION__ =3D "attr_dup2"
#4 0x00007f66e92f86a2 in attrs_dup (a=3D0x7f66e9a40e80) at /build/build=
d/openldap-2.4.25/servers/slapd/attr.c:279
i =3D <optimized out>
tmp =3D 0x7f66e9a40db8
anew =3D 0x7f66e9a40e08
#5 0x00007f66e92fb83a in entry_dup2 (dest=3D0x7f66e9a2ce98, source=3D0x=
7f66e9a2cee8) at /build/buildd/openldap-2.4.25/servers/slapd/entry.c:989=
__PRETTY_FUNCTION__ =3D "entry_dup2"
#6 0x00007f66e33e147e in rwm_send_entry (op=3D0x7f66e9b06020, rs=3D0x7f=
66e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/overlays/rwm.=
c:1493
on =3D 0x7f66e99b43c0
rwmap =3D <optimized out>
e =3D 0x7f66e9a2cee8
dn =3D {bv_len =3D 0, bv_val =3D 0x0}
ndn =3D {bv_len =3D 0, bv_val =3D 0x0}
dc =3D {rwmap =3D 0x7f66e99b45a0, conn =3D 0x7f66e91dde50, ctx =3D=
0x7f66e33e5ec3 "searchEntryDN", rs =3D 0x0}
rc =3D <optimized out>
__PRETTY_FUNCTION__ =3D "rwm_send_entry"
#7 0x00007f66e33e1702 in rwm_response (op=3D0x7f66e9b06020, rs=3D0x7f66=
e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/overlays/rwm.c:=
1735
on =3D <optimized out>
rwmap =3D <optimized out>
rc =3D <optimized out>
#8 0x00007f66e935aac8 in over_back_response (op=3D0x7f66e9b06020, rs=3D=
0x7f66e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/backover.=
c:237
oi =3D <optimized out>
on =3D 0x7f66e99b43c0
rc =3D 32768
be =3D 0x7f66e99b7340
db =3D {bd_info =3D 0x7f66e99b43c0, bd_self =3D 0x7f66e99b7340, =
be_ctrls =3D "\000", '\001' <repeats 17 times>, '\000' <repeats 14 times=
>, "\001", be_flags =3D 257, be_restrictops =3D 0, be_requires =3D 0, be=
_ssf_set =3D {sss_ssf =3D 0, sss_transport =3D 0, sss_tls =3D 0, sss_sas=
l =3D 0, sss_update_ssf =3D 0, sss_update_transport =3D 0, sss_update_tl=
s =3D 0, sss_update_sasl =3D 0, sss_simple_bind =3D 0}, be_suffix =3D 0x=
7f66e99b4180, be_nsuffix =3D 0x7f66e99b41b0, be_schemadn =3D {bv_len =3D=
0, bv_val =3D 0x0}, be_schemandn =3D {bv_len =3D 0, bv_val =3D 0x0}, be=
_rootdn =3D {bv_len =3D 0, bv_val =3D 0x0}, be_rootndn =3D {bv_len =3D 0=
, bv_val =3D 0x0}, be_rootpw =3D {bv_len =3D 0, bv_val =3D 0x0}, be_max_=
deref_depth =3D 15, be_def_limit =3D {lms_t_soft =3D 3600, lms_t_hard =3D=
0, lms_s_soft =3D 100, lms_s_hard =3D 0, lms_s_unchecked =3D -1, lms_s_=
pr =3D 0, lms_s_pr_hide =3D 0, lms_s_pr_total =3D 0}, be_limits =3D 0x0,=
be_acl =3D 0x0, be_dfltaccess =3D ACL_READ, be_update_ndn =3D {bv_len =3D=
0, bv_val =3D 0x0}, be_update_refs =3D 0x0, be_pending_csn_list =3D 0x7=
f66e99d2850, be_pcl_mutex =3D {__data =3D {__lock =3D 0, __count =3D 0, =
__owner =3D 0, __nusers =3D 0, __kind =3D 0, __spins =3D 0, __list =3D {=
__prev =3D 0x0, __next =3D 0x0}}, __size =3D '\000' <repeats 39 times>, =
__align =3D 0}, be_syncinfo =3D 0x0, be_pb =3D 0x0, be_cf_ocs =3D 0x7f66=
e3c160a0, be_private =3D 0x7f66e99b7500, be_next =3D {stqe_next =3D 0x0}=
}
#9 0x00007f66e92ff267 in slap_response_play (op=3D0x7f66e9b06020, rs=3D=
0x7f66e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/result.c:=
505
sc_next =3D 0x0
sc_nextp =3D 0x7f66e247a690
rc =3D 32768
sc =3D 0x7f66e247a5e0
scp =3D 0x7f66e247a5e0
#10 0x00007f66e9301d6d in slap_send_search_entry (op=3D0x7f66e9b06020, r=
s=3D0x7f66e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/resul=
t.c:997
berbuf =3D {buffer =3D "\230\244G\342f\177\000\000\222M\303\350f=
\177\000\000x\n\244\351f\177\000\000 ", '\000' <repeats 15 times>, "\n\0=
23\000\000\000\000\000\000 `\260\351f\177\000\000\020\000\000\000f\177\0=
00\000\240\243G\342f\177\000\000\060\243G\342f\177\000\000d\001\000\000\=
000\000\000\000n\374\300\351f\177\000\000 \247c\351f\177\000\000{\001\00=
0\000\000\000\000\000=C8=A3G\342f\177\000\000\220\n\244\351f\177\000\000=
\000\000\000\000\000\000\000\000P\374\300\351f\177\000\000S\374\300\351f=
\177\000\000\000\000\000\000\000\000\000\000P\374\300\351f\177\000\000\2=
60]\260\351f\177\000\000\260]\260\351f\177\000\000p\271G\342f\177\000\00=
0\367\377\377\377\000\000\000\000\000u\233\351f\177\000\000\000\000\000\=
000\000\000\000\000\342/\346\350f\177\000\000\002\000\001\000\000\001\00=
0\000\000\000\000\000\000\000\000\000\202\001", '\000' <repeats 13 times=
>, ialign =3D -498621288, lalign =3D 140079859737752, falign =3D -9.2069=
0575e+20, dalign =3D 6.9208646370683671e-310, palign =3D 0x7f66e247a498 =
"\021"}
ber =3D 0x7f66e247a2c0
a =3D <optimized out>
i =3D <optimized out>
j =3D <optimized out>
rc =3D 0
bytes =3D <optimized out>
userattrs =3D <optimized out>
acl_state =3D {as_desc =3D 0x0, as_access =3D ACL_NONE, as_vd_ac=
l =3D 0x0, as_vd_acl_present =3D 0, as_vd_acl_count =3D 0, as_vd_mask =3D=
1, as_result =3D -1, as_fe_done =3D 0}
attrsonly =3D <optimized out>
ad_entry =3D 0x7f66e995acc0
e_flags =3D 0x0
#11 0x00007f66e3a00939 in ldap_back_search (op=3D0x7f66e9b06020, rs=3D<o=
ptimized out>) at /build/buildd/openldap-2.4.25/servers/slapd/back-ldap/=
search.c:335
ent =3D {e_id =3D 0, e_name =3D {bv_len =3D 17, bv_val =3D 0x7f6=
6e9b068f8 "dc=3Dchalmers,dc=3Dse"}, e_nname =3D {bv_len =3D 17, bv_val =3D=
0x7f66e9b06958 "dc=3Dchalmers,dc=3Dse"}, e_attrs =3D 0x7f66e9a407c8, e_=
ocflags =3D 0, e_bv =3D {bv_len =3D 0, bv_val =3D 0x0}, e_private =3D 0x=
0}
bdn =3D {bv_len =3D 17, bv_val =3D 0x7f66e9c0fc59 "dc=3Dchalmers=
,dc=3Dse"}
li =3D <optimized out>
lc =3D 0x7f66e9c06400
tv =3D {tv_sec =3D 0, tv_usec =3D 100000}
stoptime =3D 1327979004
res =3D 0x7f66e9c0fa80
e =3D <optimized out>
rc =3D 0
msgid =3D 2
match =3D {bv_len =3D 0, bv_val =3D 0x0}
filter =3D {bv_len =3D 15, bv_val =3D 0x7f66e9b06680 "(objectCla=
ss=3D*)"}
i =3D <optimized out>
attrs =3D <optimized out>
freetext =3D 0
filter_undef =3D 0
do_retry =3D 0
dont_retry =3D 1
ctrls =3D 0x0
references =3D 0x0
__PRETTY_FUNCTION__ =3D "ldap_back_search"
#12 0x00007f66e35ebca7 in translucent_search (op=3D0x7f66e9b06020, rs=3D=
0x7f66e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/overlays/=
translucent.c:1111
on =3D 0x7f66e99b7160
ov =3D 0x7f66e99b7340
cb =3D {sc_next =3D 0x7f66e247a690, sc_response =3D 0x7f66e35ebc=
d0 <translucent_search_cb>, sc_cleanup =3D 0, sc_private =3D 0x7f66e247a=
5b0}
tc =3D {db =3D 0x7f66e247a6b0, on =3D 0x7f66e99b7160, orig =3D 0=
x7f66e9b06658, list =3D 0x0, step =3D 0, slimit =3D 100, attrs =3D 0x7f6=
6e9b066a0}
fl =3D 0x0
fr =3D 0x0
fbv =3D <optimized out>
rc =3D 0
#13 0x00007f66e935b5aa in overlay_op_walk (op=3D0x7f66e9b06020, rs=3D0x7=
f66e247b940, which=3Dop_search, oi=3D0x7f66e99b41e0, on=3D0x7f66e99b7160=
) at /build/buildd/openldap-2.4.25/servers/slapd/backover.c:659
func =3D 0x7f66e99b71b8
rc =3D 32768
#14 0x00007f66e935b76b in over_op_func (op=3D0x7f66e9b06020, rs=3D<optim=
ized out>, which=3D<optimized out>) at /build/buildd/openldap-2.4.25/ser=
vers/slapd/backover.c:721
oi =3D <optimized out>
on =3D <optimized out>
be =3D 0x7f66e99b3f70
db =3D {bd_info =3D 0x7f66e99b7160, bd_self =3D 0x7f66e99b3f70, =
be_ctrls =3D "\000", '\001' <repeats 15 times>, '\000' <repeats 16 times=
>, be_flags =3D 275, be_restrictops =3D 0, be_requires =3D 0, be_ssf_set=
=3D {sss_ssf =3D 0, sss_transport =3D 0, sss_tls =3D 0, sss_sasl =3D 0,=
sss_update_ssf =3D 0, sss_update_transport =3D 0, sss_update_tls =3D 0,=
sss_update_sasl =3D 0, sss_simple_bind =3D 0}, be_suffix =3D 0x7f66e99b=
4180, be_nsuffix =3D 0x7f66e99b41b0, be_schemadn =3D {bv_len =3D 0, bv_v=
al =3D 0x0}, be_schemandn =3D {bv_len =3D 0, bv_val =3D 0x0}, be_rootdn =
=3D {bv_len =3D 0, bv_val =3D 0x0}, be_rootndn =3D {bv_len =3D 0, bv_val=
=3D 0x0}, be_rootpw =3D {bv_len =3D 0, bv_val =3D 0x0}, be_max_deref_de=
pth =3D 15, be_def_limit =3D {lms_t_soft =3D 3600, lms_t_hard =3D 0, lms=
_s_soft =3D 100, lms_s_hard =3D 0, lms_s_unchecked =3D -1, lms_s_pr =3D =
0, lms_s_pr_hide =3D 0, lms_s_pr_total =3D 0}, be_limits =3D 0x0, be_acl=
=3D 0x0, be_dfltaccess =3D ACL_READ, be_update_ndn =3D {bv_len =3D 0, b=
v_val =3D 0x0}, be_update_refs =3D 0x0, be_pending_csn_list =3D 0x7f66e9=
9d27c0, be_pcl_mutex =3D {__data =3D {__lock =3D 0, __count =3D 0, __own=
er =3D 0, __nusers =3D 0, __kind =3D 0, __spins =3D 0, __list =3D {__pre=
v =3D 0x0, __next =3D 0x0}}, __size =3D '\000' <repeats 39 times>, __ali=
gn =3D 0}, be_syncinfo =3D 0x0, be_pb =3D 0x0, be_cf_ocs =3D 0x7f66e39f3=
020, be_private =3D 0x7f66e99b4100, be_next =3D {stqe_next =3D 0x0}}
cb =3D {sc_next =3D 0x0, sc_response =3D 0x7f66e935aa50 <over_ba=
ck_response>, sc_cleanup =3D 0, sc_private =3D 0x7f66e99b41e0}
sc =3D <optimized out>
rc =3D 32768
__PRETTY_FUNCTION__ =3D "over_op_func"
#15 0x00007f66e92f2559 in fe_op_search (op=3D0x7f66e9b06020, rs=3D0x7f66=
e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/search.c:372
bd =3D 0x7f66e95f9a80
#16 0x00007f66e92f1e36 in do_search (op=3D0x7f66e9b06020, rs=3D0x7f66e24=
7b940) at /build/buildd/openldap-2.4.25/servers/slapd/search.c:217
base =3D {bv_len =3D 17, bv_val =3D 0x7f66e9b05f9b "dc=3Dchalmer=
s,dc=3Dse"}
siz =3D 1
off =3D 0
i =3D <optimized out>
#17 0x00007f66e92ef6b7 in connection_operation (ctx=3D0x7f66e247bb60, ar=
g_v=3D0x7f66e9b06020) at /build/buildd/openldap-2.4.25/servers/slapd/con=
nection.c:1113
rc =3D 80
cancel =3D <optimized out>
op =3D 0x7f66e9b06020
rs =3D {sr_type =3D REP_SEARCH, sr_tag =3D 0, sr_msgid =3D 0, sr=
_err =3D 0, sr_matched =3D 0x0, sr_text =3D 0x0, sr_ref =3D 0x0, sr_ctrl=
s =3D 0x0, sr_un =3D {sru_search =3D {r_entry =3D 0x7f66e9a2cee8, r_attr=
_flags =3D 17, r_operational_attrs =3D 0x7f66e9a40ac0, r_attrs =3D 0x7f6=
6e9b066a0, r_nentries =3D 0, r_v2ref =3D 0x0}, sru_sasl =3D {r_sasldata =
=3D 0x7f66e9a2cee8}, sru_extended =3D {r_rspoid =3D 0x7f66e9a2cee8 "", r=
_rspdata =3D 0x11}}, sr_flags =3D 2}
tag =3D 99
opidx =3D SLAP_OP_SEARCH
conn =3D 0x7f66e91dde50
memctx =3D 0x7f66e9b05f50
memctx_null =3D 0x0
memsiz =3D 1048576
__PRETTY_FUNCTION__ =3D "connection_operation"
#18 0x00007f66e92ef9de in connection_read_thread (ctx=3D0x7f66e247bb60, =
argv=3D<optimized out>) at /build/buildd/openldap-2.4.25/servers/slapd/c=
onnection.c:1249
rc =3D <optimized out>
cri =3D {op =3D 0x7f66e9b06020, func =3D 0, arg =3D 0x0, ctx =3D=
0x7f66e247bb60, nullop =3D <optimized out>}
s =3D <optimized out>
#19 0x00007f66e8e4e85a in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r=
-2.4.so.2
No symbol table info available.
#20 0x00007f66e7fa4efc in start_thread () from /lib/x86_64-linux-gnu/lib=
pthread.so.0
No symbol table info available.
#21 0x00007f66e7cdf89d in clone () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#22 0x0000000000000000 in ?? ()
No symbol table info available.
(gdb) info registers
rax 0x0 0
rbx 0x7fff061cce37 140733295939127
rcx 0xffffffffffffffff -1
rdx 0x6 6
rsi 0x130a 4874
rdi 0x1300 4864
rbp 0x7f66e7d591da 0x7f66e7d591da
rsp 0x7f66e2479d28 0x7f66e2479d28
r8 0x7f66e247c700 140079859746560
r9 0x3c206a60206e6f69 4332579802623930217
r10 0x8 8
r11 0x206 518
r12 0xec 236
r13 0x7f66e9394c94 140079976238228
r14 0x7f66e9394ca1 140079976238241
r15 0x7f66e7d591da 140079952925146
rip 0x7f66e7c343a5 0x7f66e7c343a5 <raise+53>
eflags 0x206 [ PF IF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
(gdb) x/16i $pc
=3D> 0x7f66e7c343a5 <raise+53>: cmp $0xfffffffffffff000,%rax
0x7f66e7c343ab <raise+59>: ja 0x7f66e7c343bf <raise+79>
0x7f66e7c343ad <raise+61>: repz retq =
0x7f66e7c343af <raise+63>: nop
0x7f66e7c343b0 <raise+64>: test %eax,%eax
0x7f66e7c343b2 <raise+66>: jg 0x7f66e7c34395 <raise+37>
0x7f66e7c343b4 <raise+68>: test $0x7fffffff,%eax
0x7f66e7c343b9 <raise+73>: je 0x7f66e7c343d0 <raise+96>
0x7f66e7c343bb <raise+75>: neg %eax
0x7f66e7c343bd <raise+77>: jmp 0x7f66e7c34395 <raise+37>
0x7f66e7c343bf <raise+79>: mov 0x361a52(%rip),%rdx # 0x7f66=
e7f95e18
0x7f66e7c343c6 <raise+86>: neg %eax
0x7f66e7c343c8 <raise+88>: mov %eax,%fs:(%rdx)
0x7f66e7c343cb <raise+91>: or $0xffffffffffffffff,%rax
0x7f66e7c343cf <raise+95>: retq =
0x7f66e7c343d0 <raise+96>: mov %esi,%eax
(gdb) thread apply all backtrace
Thread 3 (Thread 0x7f66e247c700 (LWP 4874)):
#0 0x00007f66e7c343a5 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f66e7c37b0b in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007f66e7c2cd4d in __assert_fail () from /lib/x86_64-linux-gnu/li=
bc.so.6
#3 0x00007f66e92f8293 in attr_dup2 (tmp=3D0x7f66e9a40db8, a=3D0x7f66e9a=
40e80) at /build/buildd/openldap-2.4.25/servers/slapd/attr.c:236
#4 0x00007f66e92f86a2 in attrs_dup (a=3D0x7f66e9a40e80) at /build/build=
d/openldap-2.4.25/servers/slapd/attr.c:279
#5 0x00007f66e92fb83a in entry_dup2 (dest=3D0x7f66e9a2ce98, source=3D0x=
7f66e9a2cee8) at /build/buildd/openldap-2.4.25/servers/slapd/entry.c:989=
#6 0x00007f66e33e147e in rwm_send_entry (op=3D0x7f66e9b06020, rs=3D0x7f=
66e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/overlays/rwm.=
c:1493
#7 0x00007f66e33e1702 in rwm_response (op=3D0x7f66e9b06020, rs=3D0x7f66=
e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/overlays/rwm.c:=
1735
#8 0x00007f66e935aac8 in over_back_response (op=3D0x7f66e9b06020, rs=3D=
0x7f66e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/backover.=
c:237
#9 0x00007f66e92ff267 in slap_response_play (op=3D0x7f66e9b06020, rs=3D=
0x7f66e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/result.c:=
505
#10 0x00007f66e9301d6d in slap_send_search_entry (op=3D0x7f66e9b06020, r=
s=3D0x7f66e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/resul=
t.c:997
#11 0x00007f66e3a00939 in ldap_back_search (op=3D0x7f66e9b06020, rs=3D<o=
ptimized out>) at /build/buildd/openldap-2.4.25/servers/slapd/back-ldap/=
search.c:335
#12 0x00007f66e35ebca7 in translucent_search (op=3D0x7f66e9b06020, rs=3D=
0x7f66e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/overlays/=
translucent.c:1111
#13 0x00007f66e935b5aa in overlay_op_walk (op=3D0x7f66e9b06020, rs=3D0x7=
f66e247b940, which=3Dop_search, oi=3D0x7f66e99b41e0, on=3D0x7f66e99b7160=
) at /build/buildd/openldap-2.4.25/servers/slapd/backover.c:659
#14 0x00007f66e935b76b in over_op_func (op=3D0x7f66e9b06020, rs=3D<optim=
ized out>, which=3D<optimized out>) at /build/buildd/openldap-2.4.25/ser=
vers/slapd/backover.c:721
#15 0x00007f66e92f2559 in fe_op_search (op=3D0x7f66e9b06020, rs=3D0x7f66=
e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/search.c:372
#16 0x00007f66e92f1e36 in do_search (op=3D0x7f66e9b06020, rs=3D0x7f66e24=
7b940) at /build/buildd/openldap-2.4.25/servers/slapd/search.c:217
#17 0x00007f66e92ef6b7 in connection_operation (ctx=3D0x7f66e247bb60, ar=
g_v=3D0x7f66e9b06020) at /build/buildd/openldap-2.4.25/servers/slapd/con=
nection.c:1113
#18 0x00007f66e92ef9de in connection_read_thread (ctx=3D0x7f66e247bb60, =
argv=3D<optimized out>) at /build/buildd/openldap-2.4.25/servers/slapd/c=
onnection.c:1249
#19 0x00007f66e8e4e85a in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r=
-2.4.so.2
#20 0x00007f66e7fa4efc in start_thread () from /lib/x86_64-linux-gnu/lib=
pthread.so.0
#21 0x00007f66e7cdf89d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#22 0x0000000000000000 in ?? ()
Thread 2 (Thread 0x7f66e2c7d700 (LWP 4865)):
#0 0x00007f66e7cdfef3 in epoll_wait () from /lib/x86_64-linux-gnu/libc.=
so.6
#1 0x00007f66e92ea440 in slapd_daemon_task (ptr=3D<optimized out>) at /=
build/buildd/openldap-2.4.25/servers/slapd/daemon.c:2528
#2 0x00007f66e7fa4efc in start_thread () from /lib/x86_64-linux-gnu/lib=
pthread.so.0
#3 0x00007f66e7cdf89d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#4 0x0000000000000000 in ?? ()
Thread 1 (Thread 0x7f66e928d740 (LWP 4864)):
#0 0x00007f66e7fa61f8 in pthread_join () from /lib/x86_64-linux-gnu/lib=
pthread.so.0
#1 0x00007f66e92ec9a2 in slapd_daemon () at /build/buildd/openldap-2.4.=
25/servers/slapd/daemon.c:2922
#2 0x00007f66e92d4013 in main (argc=3D3, argv=3D<optimized out>) at /bu=
ild/buildd/openldap-2.4.25/servers/slapd/main.c:1008
(gdb) quit
A debugging session is active.
Inferior 1 [process 4864] will be detached.
Quit anyway? (y or n) Quitting: Can't detach Thread 0x7f66e2c7d700 (LWP =
4865): No such process
------------hvfQvbIMuXxQGZ2Ols8tGf--
11 years, 4 months
Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
by hyc＠symas.com
mattias(a)centaurix.com wrote:
> Full_Name: Mattias Andersson
> Version: 2.4.25
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (83.182.107.220)
Please provide a full gdb backtrace from the assertion failure. I've
reproduced this configuration locally but see no crash using ldapsearch. I
don't have the Softerra browser.
> I have configured a proxy server using both the relay backend and the
> translucent overlay:
>
> backend hdb
> backend relay
>
> database hdb
> directory /var/lib/ldap
> suffix "dc=foo,dc=example,dc=com"
> rootdn "cn=admin,dc=foo,dc=example,dc=com"
> rootpw secret
> index objectClass eq
>
> database relay
> suffix "dc=example,dc=com"
> overlay rwm
> rwm-suffixmassage "dc=foo,dc=example,dc=com"
> overlay translucent
> uri ldap://ldap.example.com
>
> This configuration makes it possible for me to override attributes in the remote
> ldap directory and at the same time extend the local directory with new entries.
> This has been tested and works for authorization in a linux environment.
>
> If I issue an LDAP search query, as follows,
>
> ldapsearch -x -b dc=chalmers,dc=se -s base "(objectClass=*)" 1.1
>
> it will yield the following debug output:
>
> slapd starting
> conn=1000 fd=11 ACCEPT from IP=127.0.0.1:36838 (IP=0.0.0.0:389)
> conn=1000 op=0 BIND dn="" method=128
> conn=1000 op=0 RESULT tag=97 err=0 text=
> conn=1000 op=1 SRCH base="dc=example,dc=com" scope=0 deref=0
> filter="(objectClass=*)"
> conn=1000 op=1 SRCH attr=1.1
> conn=1000 op=1: back-relay for DN="dc=example,dc=com" would call self.
> conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
> conn=1000 op=2 UNBIND
> conn=1000 fd=11 closed
>
> However, if I query the server using the Softerra LDAP Administrator software
> (Windows), the slapd daemon crashes with an assertion error:
>
> slapd starting
> conn=1000 fd=11 ACCEPT from IP=11.22.33.44:54752 (IP=0.0.0.0:389)
> conn=1000 op=0 BIND dn="" method=128
> conn=1000 op=0 RESULT tag=97 err=0 text=
> conn=1000 op=1 SRCH base="dc=example,dc=com" scope=0 deref=0
> filter="(objectClass=*)"
> conn=1000 op=1 SRCH attr=1.1
> conn=1000 op=1: back-relay for DN="dc=example,dc=com" would call self.
> slapd: /build/buildd/openldap-2.4.25/servers/slapd/attr.c:236: attr_dup2:
> Assertion `j< i' failed.
> Aborted
>
> This is a security vulnerability, since it would be enough to send an LDAP query
> to take down the server.
We don't consider crashes/DOS to be a security vulnerability. A vulnerability
is anything which allows users to see information they should not be allowed
to see; in the case of a crash no information can be retrieved so all data is
completely secure.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
11 years, 4 months
(ITS#7143) Assertion error (crash); using relay backend and translucent overlay
by mattias＠centaurix.com
Full_Name: Mattias Andersson
Version: 2.4.25
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (83.182.107.220)
I have configured a proxy server using both the relay backend and the
translucent overlay:
backend hdb
backend relay
database hdb
directory /var/lib/ldap
suffix "dc=foo,dc=example,dc=com"
rootdn "cn=admin,dc=foo,dc=example,dc=com"
rootpw secret
index objectClass eq
database relay
suffix "dc=example,dc=com"
overlay rwm
rwm-suffixmassage "dc=foo,dc=example,dc=com"
overlay translucent
uri ldap://ldap.example.com
This configuration makes it possible for me to override attributes in the remote
ldap directory and at the same time extend the local directory with new entries.
This has been tested and works for authorization in a linux environment.
If I issue an LDAP search query, as follows,
ldapsearch -x -b dc=chalmers,dc=se -s base "(objectClass=*)" 1.1
it will yield the following debug output:
slapd starting
conn=1000 fd=11 ACCEPT from IP=127.0.0.1:36838 (IP=0.0.0.0:389)
conn=1000 op=0 BIND dn="" method=128
conn=1000 op=0 RESULT tag=97 err=0 text=
conn=1000 op=1 SRCH base="dc=example,dc=com" scope=0 deref=0
filter="(objectClass=*)"
conn=1000 op=1 SRCH attr=1.1
conn=1000 op=1: back-relay for DN="dc=example,dc=com" would call self.
conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
conn=1000 op=2 UNBIND
conn=1000 fd=11 closed
However, if I query the server using the Softerra LDAP Administrator software
(Windows), the slapd daemon crashes with an assertion error:
slapd starting
conn=1000 fd=11 ACCEPT from IP=11.22.33.44:54752 (IP=0.0.0.0:389)
conn=1000 op=0 BIND dn="" method=128
conn=1000 op=0 RESULT tag=97 err=0 text=
conn=1000 op=1 SRCH base="dc=example,dc=com" scope=0 deref=0
filter="(objectClass=*)"
conn=1000 op=1 SRCH attr=1.1
conn=1000 op=1: back-relay for DN="dc=example,dc=com" would call self.
slapd: /build/buildd/openldap-2.4.25/servers/slapd/attr.c:236: attr_dup2:
Assertion `j < i' failed.
Aborted
This is a security vulnerability, since it would be enough to send an LDAP query
to take down the server.
Mattias
11 years, 4 months
(ITS#7142) slapadd with tool-threads hangs on failure
by h.b.furuseth＠usit.uio.no
Full_Name: Hallvard B Furuseth
Version: 2.4.28, master
OS: Linux x86_64
URL: http://folk.uio.no/hbf/toobig.sh
Submission from: (NULL) (195.1.106.125)
Submitted by: hallvard
slapadd hangs if bi_tool_entry_put() fails.
Tested with back-ldif patched for bi_tool_entry_put() to return NOID
after 6 entries, and on master with mdb and an LDIF > DB maxsize.
Test program enclosed. Backtrace:
Thread 2 (Thread 0x7fb3745fd700 (LWP 31479)):
#0 0x000000371fc0b3dc in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib64/libpthread.so.0
#1 0x000000000048acaf in getrec_thr (ctx=<value optimized out>)
at slapadd.c:296
#2 0x000000371fc077f1 in start_thread () from /lib64/libpthread.so.0
Thread 1 (Thread 0x7fb37542e7c0 (LWP 31478)):
#0 0x000000371fc0804d in pthread_join () from /lib64/libpthread.so.0
#1 0x000000000048a8e5 in slapadd (argc=<value optimized out>,
argv=<value optimized out>) at slapadd.c:454
#2 0x0000000000406ea5 in main (argc=5, argv=<value optimized out>)
at main.c:655
I don't want to touch that code, don't remember why nearby code uses
ldap_pvt_tread_yield() instead of the clean way of having two conds
(one for producer and one for consumer to wait for).
11 years, 4 months
Re: (ITS#7141) Segmentation fault during stopping slapd
by h.b.furuseth＠usit.uio.no
On Sat, 28 Jan 2012 16:52:05 GMT, michael(a)stroeder.com wrote:
> Hmm, it seems I get better result linking smbk5pwd with
> contrib/slapd-modules/smbk5pwd/Makefile containing:
>
> LDAP_LIB=-lldap_r -llber -L../../../libraries/libldap_r/.libs
> -L../../../libraries/liblber/.libs
>
> instead of just
>
> LDAP_LIB=-lldap_r -llber
>
> Is that the right solution when rpath is already set when invoking
> configure?
If you build *and install* the rest of OpenLDAP first and then build
smbk5pwd, I imagine it'll work fine if -L and -rpath are the same.
Otherwise you should point -L at where all the
libraries-to-be-installed
are, which with a dynamic build is the .lib/ directories.
After all -L is for build time and -rpath for runtime, and they should
be set so that you build against the same libraries you will run with.
At least I hope that's all. I wouldn't be surprised if some libtool
magic introduces more complications:-(
--
Hallvard
11 years, 4 months