openldap-bugs January 2012

openldap-bugs@openldap.org

22 participants
76 discussions

(ITS#7144) reproducible segfault on slave/consumer during sync-replication
by sven＠svenhartge.de 31 Jan '12

31 Jan '12

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?

1 0

Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
by hyc＠symas.com 31 Jan '12

31 Jan '12

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/

1 0

Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
by mattias＠centaurix.com 31 Jan '12

31 Jan '12

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

1 0

Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
by hyc＠symas.com 30 Jan '12

30 Jan '12

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--

1 0

Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
by hyc＠symas.com 30 Jan '12

30 Jan '12

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/

1 0

Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
by mattias＠centaurix.com 30 Jan '12

30 Jan '12

------------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--

1 0

Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
by hyc＠symas.com 30 Jan '12

30 Jan '12

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/

1 0

(ITS#7143) Assertion error (crash); using relay backend and translucent overlay
by mattias＠centaurix.com 29 Jan '12

29 Jan '12

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

1 0

(ITS#7142) slapadd with tool-threads hangs on failure
by h.b.furuseth＠usit.uio.no 28 Jan '12

28 Jan '12

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).

1 0

Re: (ITS#7141) Segmentation fault during stopping slapd
by h.b.furuseth＠usit.uio.no 28 Jan '12

28 Jan '12

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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2012