openldap-bugs April 2016

openldap-bugs@openldap.org

19 participants
66 discussions

(ITS#8414) test008 is non portable due to use of "time" command
by quanah＠openldap.org 29 Apr '16

29 Apr '16

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) test008 uses the "time" command as part of the test script. However, that is not portable as the default /bin/sh shell on Debian and Ubuntu does not have "time" as a built-in. "time" is only present there for debugging, and is not required for the test itself. Time to remove time.

1 0

Re: (ITS#8404) Fix for an assertion failure when olcDbRewrite is modified on a meta or asyncmeta database
by hyc＠symas.com 28 Apr '16

28 Apr '16

nivanova(a)symas.com wrote: > Full_Name: Nadezhda Ivanova > Version: 2.5 > OS: Ubuntu 14.04 > URL: ftp://ftp.openldap.org/incoming/nadezhda-ivanova-160414.patch > Submission from: (NULL) (78.83.54.234) > > > The problem was reproduced when attempting to modify the dynamic configuration > of meta and asyncmeta rewrite engine. On a meta database that has rewrite > enabled and some rewrite rules configured, execute ldapmodify with the following > LDIF: > dn: olcMetaSub={0}uri,olcDatabase={1}meta,cn=config > replace: olcDbRewrite > olcDbRewrite: rewriteEngine "off" Hm, multiple problems with this patch: > diff --git a/servers/slapd/back-asyncmeta/config.c b/servers/slapd/back-asyncmeta/config.c > index 1801a55..a4fbb91 100644 > --- a/servers/slapd/back-asyncmeta/config.c > +++ b/servers/slapd/back-asyncmeta/config.c > @@ -1797,14 +1797,66 @@ asyncmeta_back_cf_gen( ConfigArgs *c ) > > case LDAP_BACK_CFG_SUFFIXM: /* unused */ > case LDAP_BACK_CFG_REWRITE: > - if ( mt->mt_rwmap.rwm_bva_rewrite ) { > - ber_bvarray_free( mt->mt_rwmap.rwm_bva_rewrite ); > - mt->mt_rwmap.rwm_bva_rewrite = NULL; > - } > - if ( mt->mt_rwmap.rwm_rw ) > + { > + char *argv0; > + if ( c->valx >= 0 ) { > + int i; > + > + for ( i = 0; !BER_BVISNULL( &mt->mt_rwmap.rwm_bva_rewrite[ i ] ); i++ ) Need a semicolon for the empty for-loop. Or, if it's intended that the following if-block is part of the loop, it needs to be properly enclosed in braces and indented. > + > + if ( c->valx >= i ) { > + rc = 1; > + break; > + } > + ber_memfree( mt->mt_rwmap.rwm_bva_rewrite[ c->valx ].bv_val ); > + for ( i = c->valx; !BER_BVISNULL( &mt->mt_rwmap.rwm_bva_rewrite[ i + 1 ] ); i++ ) > + { > + mt->mt_rwmap.rwm_bva_rewrite[ i ] = mt->mt_rwmap.rwm_bva_rewrite[ i + 1 ]; > + } > + BER_BVZERO( &mt->mt_rwmap.rwm_bva_rewrite[ i ] ); > + > rewrite_info_delete( &mt->mt_rwmap.rwm_rw ); > - break; > + assert( mt->mt_rwmap.rwm_rw == NULL ); > + > + rc = asyncmeta_rwi_init( &mt->mt_rwmap.rwm_rw ); > + > + for ( i = 0; !BER_BVISNULL( &mt->mt_rwmap.rwm_bva_rewrite[ i ] ); i++ ) > + { > + ConfigArgs ca = { 0 }; > + > + ca.line = mt->mt_rwmap.rwm_bva_rewrite[ i ].bv_val; > + ca.argc = 0; Unnecessary initialization, you already set all of ca = {0}. > + init_config_argv( &ca ); > + config_parse_ldif( &ca ); > + > + argv0 = ca.argv[ 0 ]; What is argv0 being saved for? > + if ( !strcasecmp( ca.argv[0], "suffixmassage" )) { > + rc = asyncmeta_suffixm_config( &ca, ca.argc, ca.argv, mt ); > + } else { > + rc = rewrite_parse( mt->mt_rwmap.rwm_rw, > + c->fname, c->lineno, ca.argc, ca.argv ); > + } > + > + ca.argv[ 0 ] = argv0; Why is argv0 being restored? All you're doing after this is freeing ca.argv anyway. > + > + ch_free( ca.tline ); > + ch_free( ca.argv ); > > + assert( rc == 0 ); > + } > + > + } else if ( mt->mt_rwmap.rwm_rw != NULL ) { > + if ( mt->mt_rwmap.rwm_bva_rewrite ) { > + ber_bvarray_free( mt->mt_rwmap.rwm_bva_rewrite ); > + mt->mt_rwmap.rwm_bva_rewrite = NULL; > + } > + if ( mt->mt_rwmap.rwm_rw ) > + rewrite_info_delete( &mt->mt_rwmap.rwm_rw ); > + > + asyncmeta_rwi_init( &mt->mt_rwmap.rwm_rw ); > + } > + } > + break; > case LDAP_BACK_CFG_MAP: > if ( mt->mt_rwmap.rwm_bva_map ) { > ber_bvarray_free( mt->mt_rwmap.rwm_bva_map ); -- -- 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#8413) Assertion in back-mdb/search.c during replication
by quanah＠openldap.org 27 Apr '16

27 Apr '16

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) During replication from the accesslog DB, in a 4-way MMR setup, various masters periodically crash with slapd: search.c:1246: oc_filter: Assertion `f != ((void *)0)' failed. This is back-mdb/search.c, not slapd-search.c This is triggered when a NULL filter is passed through. However, it should be impossible for the filter generated by str2filter to ever fail.

1 0

ITS#8410 published: SECURITY: LDAP connection issue with
by openldap-its＠OpenLDAP.org 26 Apr '16

26 Apr '16

Private ITS#8410 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=8410

1 0

ITS#8405 published: SECURITY: LDAP connection issue
by openldap-its＠OpenLDAP.org 26 Apr '16

26 Apr '16

Private ITS#8405 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=8405

1 0

Re: (ITS#8412) mdb_cursor_del followed by MDB_NEXT_DUP leads to unexpected behaviour
by hyc＠symas.com 26 Apr '16

26 Apr '16

lukaswhl(a)gmail.com wrote: > Full_Name: Lukas W > Version: mdb.master 37081325f7356587c5e6ce4c1f36c3b303fa718c > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2407:7000:9a07:8600::2) > > > The current behaviour of MDB_NEXT_DUP after a mdb_cursor_del call is > inconsistent with those of other OPs. For instance, MDB_NEXT does not change the > cursor's position, as this was already done by mdb_cursor_del. As far as I > understand, mdb_cursor_get can be expected to behave just like usual, whether > mdb_cursor_get was preceded by a mdb_cursor_del call or not. This saves extra > checks when e.g. removing particular items in a loop based on some criterion (as > described and discussed in > http://www.openldap.org/lists/openldap-devel/201502/msg00027.html and > follow-ups). > > However, this does not apply to MDB_NEXT_DUP. Consider a DB containing the > following three items: > > #1: "a" --> 1 > #2: "b" --> 1 > #3: 2b2b" --> 2 > > Let's say we have a cursor that points to #1. After calling mdb_cursor_del, #1 > is removed and the cursor points to #2 (though this is not documented anywhere). > We then call mdb_cursor_get with MDB_NEXT_DUP. We'd expect this call to return > MDB_NOTFOUND, as #1 was the last item with "a" as its key. This is also what it > would return if mdb_cursor_del was not called. But in fact, MDB_SUCCESS is > returned, making anyone who's unaware of this behaviour believe that there's > another item with the key "a". In my particular case, this leads to #2 being > deleted as well, even though I only expected to touch items with the key "a", > which is why I'm using MDB_NEXT_DUP instead of MDB_NEXT in the first place. > In a nutshell, MDB_NEXT_DUP does the same as MDB_NEXT after a mdb_cursor_del > call, even though one would expect it not to jump across "key boundaries". > > On a side note, prior to 37081325f7356587c5e6ce4c1f36c3b303fa718c / ITS#8406 > this would have resulted in an assertion failure. > > You could classify this as a bug and adjust the behaviour to match MDB_NEXT's, > or you could document the behaviour of mdb_cursor_del regarding the cursor's > state. Either would be appreciated. Fixed in mdb.master -- -- 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#8412) mdb_cursor_del followed by MDB_NEXT_DUP leads to unexpected behaviour
by lukaswhl＠gmail.com 25 Apr '16

25 Apr '16

Full_Name: Lukas W Version: mdb.master 37081325f7356587c5e6ce4c1f36c3b303fa718c OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2407:7000:9a07:8600::2) The current behaviour of MDB_NEXT_DUP after a mdb_cursor_del call is inconsistent with those of other OPs. For instance, MDB_NEXT does not change the cursor's position, as this was already done by mdb_cursor_del. As far as I understand, mdb_cursor_get can be expected to behave just like usual, whether mdb_cursor_get was preceded by a mdb_cursor_del call or not. This saves extra checks when e.g. removing particular items in a loop based on some criterion (as described and discussed in http://www.openldap.org/lists/openldap-devel/201502/msg00027.html and follow-ups). However, this does not apply to MDB_NEXT_DUP. Consider a DB containing the following three items: #1: "a" --> 1 #2: "b" --> 1 #3: 2b2b" --> 2 Let's say we have a cursor that points to #1. After calling mdb_cursor_del, #1 is removed and the cursor points to #2 (though this is not documented anywhere). We then call mdb_cursor_get with MDB_NEXT_DUP. We'd expect this call to return MDB_NOTFOUND, as #1 was the last item with "a" as its key. This is also what it would return if mdb_cursor_del was not called. But in fact, MDB_SUCCESS is returned, making anyone who's unaware of this behaviour believe that there's another item with the key "a". In my particular case, this leads to #2 being deleted as well, even though I only expected to touch items with the key "a", which is why I'm using MDB_NEXT_DUP instead of MDB_NEXT in the first place. In a nutshell, MDB_NEXT_DUP does the same as MDB_NEXT after a mdb_cursor_del call, even though one would expect it not to jump across "key boundaries". On a side note, prior to 37081325f7356587c5e6ce4c1f36c3b303fa718c / ITS#8406 this would have resulted in an assertion failure. You could classify this as a bug and adjust the behaviour to match MDB_NEXT's, or you could document the behaviour of mdb_cursor_del regarding the cursor's state. Either would be appreciated.

1 0

Re: (ITS#8411) segfault on slapd 2.4.44
by mwtzzz＠gmail.com 24 Apr '16

24 Apr '16

Thank you. Yes. I recompiled sha2 module for 2.4.44, and it works. On Sun, Apr 24, 2016 at 8:00 AM, Howard Chu <hyc(a)symas.com> wrote: > This is ITS#8294, which was fixed in 2.4.43. You have an out-of-date sha2 > password module in your installation. Closing this ITS. > > > Michael Martinez wrote: >> >> OS: Linux rpi 4.1.13+ #826 PREEMPT Fri Nov 13 20:13:22 GMT 2015 armv6l >> GNU/Linux >> >> (gdb) info shared >>> >>> From To Syms Read Shared Object Library >> >> 0xb6f344b8 0xb6f35a10 Yes (*) >> /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so >> 0xb6f16c04 0xb6f1b0bc Yes (*) >> /usr/lib/arm-linux-gnueabihf/libltdl.so.7 >> 0xb6f0a928 0xb6f0b640 Yes (*) /lib/arm-linux-gnueabihf/libdl.so.2 >> 0xb6de0dd0 0xb6ee4b74 Yes (*) >> /usr/lib/arm-linux-gnueabihf/libdb-5.1.so >> 0xb6da6558 0xb6db7504 Yes (*) >> /usr/lib/arm-linux-gnueabihf/libsasl2.so.2 >> 0xb6d5f610 0xb6d90bac Yes (*) >> /usr/lib/arm-linux-gnueabihf/libssl.so.1.0.0 >> 0xb6c35e80 0xb6d071c0 Yes (*) >> /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 >> 0xb6bb8718 0xb6bbd1e8 Yes (*) /lib/arm-linux-gnueabihf/libcrypt.so.1 >> 0xb6ba6444 0xb6bb273c Yes (*) >> /lib/arm-linux-gnueabihf/libresolv.so.2 >> 0xb6b88eb0 0xb6b9691c Yes (*) >> /lib/arm-linux-gnueabihf/libpthread.so.0 >> 0xb6a6a4a0 0xb6b583b0 Yes (*) /lib/arm-linux-gnueabihf/libc.so.6 >> 0xb6f3e7c0 0xb6f57408 Yes (*) /lib/ld-linux-armhf.so.3 >> 0xb6a38b38 0xb6a46f7c Yes (*) /lib/arm-linux-gnueabihf/libz.so.1 >> 0xb6a1e450 0xb6a2e24c Yes (*) /lib/arm-linux-gnueabihf/libgcc_s.so.1 >> 0xb6f25268 0xb6f298e0 Yes (*) >> /usr/lib/arm-linux-gnueabihf/sasl2/libntlm.so >> 0xb69ced8c 0xb69d0ae0 Yes (*) >> /usr/lib/arm-linux-gnueabihf/sasl2/libplain.so >> 0xb69c107c 0xb69c3bbc Yes (*) >> /usr/lib/arm-linux-gnueabihf/sasl2/libsasldb.so >> 0xb69ad400 0xb69b59e4 Yes (*) >> /usr/lib/arm-linux-gnueabihf/sasl2/libdigestmd5.so >> 0xb699fe04 0xb69a2004 Yes (*) >> /usr/lib/arm-linux-gnueabihf/sasl2/libcrammd5.so >> 0xb6993d5c 0xb69957f0 Yes (*) >> /usr/lib/arm-linux-gnueabihf/sasl2/libanonymous.so >> 0xb6987d50 0xb6989974 Yes (*) >> /usr/lib/arm-linux-gnueabihf/sasl2/liblogin.so >> 0xb6979e60 0xb697d8c0 Yes /usr/lib/ldap/slapd-sha2.so >> (*): Shared library is missing debugging information. >> >> (gdb) bt >> #0 0xb6f350a0 in memcpy () from >> /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so >> #1 0xb6c3f344 in SHA256_Update () >> from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 >> #2 0xb697a69c in chk_ssha256 (scheme=0x19e27d4, passwd=0xa11caa20, >> cred=0x1a53468, >> text=0xa11cab98) at slapd-sha2.c:256 >> #3 0x00121f58 in lutil_passwd () >> #4 0x0006ec98 in slap_passwd_check () >> #5 0x000e4db8 in bdb_bind () >> #6 0x0005bbdc in fe_op_bind () >> #7 0x0005b568 in do_bind () >> #8 0x000403b8 in ?? () >> Cannot access memory at address 0x0 >> #9 0x000403b8 in ?? () >> Cannot access memory at address 0x0 >> Backtrace stopped: previous frame identical to this frame (corrupt stack?) >> >> On Sat, Apr 23, 2016 at 6:51 PM, Howard Chu <hyc(a)symas.com> wrote: >>> >>> mwtzzz(a)gmail.com wrote: >>>> >>>> >>>> Full_Name: Michael Martinez >>>> Version: 2.4.44 >>>> OS: ubuntu wheezy >>> >>> >>> >>> There is no such OS. >>> >>>> URL: >>>> Submission from: (NULL) (99.113.34.53) >>>> >>>> >>>> After upgrading from openldap-2.4.31 to 2.4.44 I'm getting segfaults >>>> anytime I >>>> run 'passwd', attempt to ssh into the box, etc. >>>> >>>> this is on raspberry pi (debian wheezy). >>>> >>>> Previously running the latest package 2.4.31. Then installed >>>> openldap-2.4.44 >>>> from source, did slapcat from the old version and slapadd to import it >>>> to >>>> the >>>> new version. Loads fine and can run simple commands like "id" for ldap >>>> users. >>>> But get core dump with password changes, ssh from other boxes, etc. >>>> A%A[Thread debugging using libthread_db enabled] >>>> Using host libthread_db library >>>> "/lib/arm-linux-gnueabihf/libthread_db.so.1". >>>> Core was generated by `/usr/local/openldap/libexec/slapd -f >>>> /etc/ldap/slapd.conf >>>> -F /ec/ldap/slapd.d'. >>>> Program terminated with signal 11, Segmentation fault. >>>> #0 0xb6f350a0 in memcpy () from >>>> /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so >>>> (gdb) >>> >>> >>> >>> Please provide the full stack trace. >>> >>> Also output from "info shared". >>> >>> -- >>> -- Howard Chu >>> CTO, Symas Corp. http://www.symas.com >>> Director, Highland Sun http://highlandsun.com/hyc/ >>> Chief Architect, OpenLDAP http://www.openldap.org/project/ >> >> >> >> > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ -- --- Michael Martinez http://www.michael--martinez.com

1 0

Re: (ITS#8411) segfault on slapd 2.4.44
by hyc＠symas.com 24 Apr '16

24 Apr '16

This is ITS#8294, which was fixed in 2.4.43. You have an out-of-date sha2 password module in your installation. Closing this ITS. Michael Martinez wrote: > OS: Linux rpi 4.1.13+ #826 PREEMPT Fri Nov 13 20:13:22 GMT 2015 armv6l GNU/Linux > > (gdb) info shared >>From To Syms Read Shared Object Library > 0xb6f344b8 0xb6f35a10 Yes (*) /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so > 0xb6f16c04 0xb6f1b0bc Yes (*) /usr/lib/arm-linux-gnueabihf/libltdl.so.7 > 0xb6f0a928 0xb6f0b640 Yes (*) /lib/arm-linux-gnueabihf/libdl.so.2 > 0xb6de0dd0 0xb6ee4b74 Yes (*) /usr/lib/arm-linux-gnueabihf/libdb-5.1.so > 0xb6da6558 0xb6db7504 Yes (*) /usr/lib/arm-linux-gnueabihf/libsasl2.so.2 > 0xb6d5f610 0xb6d90bac Yes (*) /usr/lib/arm-linux-gnueabihf/libssl.so.1.0.0 > 0xb6c35e80 0xb6d071c0 Yes (*) > /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 > 0xb6bb8718 0xb6bbd1e8 Yes (*) /lib/arm-linux-gnueabihf/libcrypt.so.1 > 0xb6ba6444 0xb6bb273c Yes (*) /lib/arm-linux-gnueabihf/libresolv.so.2 > 0xb6b88eb0 0xb6b9691c Yes (*) /lib/arm-linux-gnueabihf/libpthread.so.0 > 0xb6a6a4a0 0xb6b583b0 Yes (*) /lib/arm-linux-gnueabihf/libc.so.6 > 0xb6f3e7c0 0xb6f57408 Yes (*) /lib/ld-linux-armhf.so.3 > 0xb6a38b38 0xb6a46f7c Yes (*) /lib/arm-linux-gnueabihf/libz.so.1 > 0xb6a1e450 0xb6a2e24c Yes (*) /lib/arm-linux-gnueabihf/libgcc_s.so.1 > 0xb6f25268 0xb6f298e0 Yes (*) > /usr/lib/arm-linux-gnueabihf/sasl2/libntlm.so > 0xb69ced8c 0xb69d0ae0 Yes (*) > /usr/lib/arm-linux-gnueabihf/sasl2/libplain.so > 0xb69c107c 0xb69c3bbc Yes (*) > /usr/lib/arm-linux-gnueabihf/sasl2/libsasldb.so > 0xb69ad400 0xb69b59e4 Yes (*) > /usr/lib/arm-linux-gnueabihf/sasl2/libdigestmd5.so > 0xb699fe04 0xb69a2004 Yes (*) > /usr/lib/arm-linux-gnueabihf/sasl2/libcrammd5.so > 0xb6993d5c 0xb69957f0 Yes (*) > /usr/lib/arm-linux-gnueabihf/sasl2/libanonymous.so > 0xb6987d50 0xb6989974 Yes (*) > /usr/lib/arm-linux-gnueabihf/sasl2/liblogin.so > 0xb6979e60 0xb697d8c0 Yes /usr/lib/ldap/slapd-sha2.so > (*): Shared library is missing debugging information. > > (gdb) bt > #0 0xb6f350a0 in memcpy () from /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so > #1 0xb6c3f344 in SHA256_Update () > from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 > #2 0xb697a69c in chk_ssha256 (scheme=0x19e27d4, passwd=0xa11caa20, > cred=0x1a53468, > text=0xa11cab98) at slapd-sha2.c:256 > #3 0x00121f58 in lutil_passwd () > #4 0x0006ec98 in slap_passwd_check () > #5 0x000e4db8 in bdb_bind () > #6 0x0005bbdc in fe_op_bind () > #7 0x0005b568 in do_bind () > #8 0x000403b8 in ?? () > Cannot access memory at address 0x0 > #9 0x000403b8 in ?? () > Cannot access memory at address 0x0 > Backtrace stopped: previous frame identical to this frame (corrupt stack?) > > On Sat, Apr 23, 2016 at 6:51 PM, Howard Chu <hyc(a)symas.com> wrote: >> mwtzzz(a)gmail.com wrote: >>> >>> Full_Name: Michael Martinez >>> Version: 2.4.44 >>> OS: ubuntu wheezy >> >> >> There is no such OS. >> >>> URL: >>> Submission from: (NULL) (99.113.34.53) >>> >>> >>> After upgrading from openldap-2.4.31 to 2.4.44 I'm getting segfaults >>> anytime I >>> run 'passwd', attempt to ssh into the box, etc. >>> >>> this is on raspberry pi (debian wheezy). >>> >>> Previously running the latest package 2.4.31. Then installed >>> openldap-2.4.44 >>> from source, did slapcat from the old version and slapadd to import it to >>> the >>> new version. Loads fine and can run simple commands like "id" for ldap >>> users. >>> But get core dump with password changes, ssh from other boxes, etc. >>> A%A[Thread debugging using libthread_db enabled] >>> Using host libthread_db library >>> "/lib/arm-linux-gnueabihf/libthread_db.so.1". >>> Core was generated by `/usr/local/openldap/libexec/slapd -f >>> /etc/ldap/slapd.conf >>> -F /ec/ldap/slapd.d'. >>> Program terminated with signal 11, Segmentation fault. >>> #0 0xb6f350a0 in memcpy () from >>> /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so >>> (gdb) >> >> >> Please provide the full stack trace. >> >> Also output from "info shared". >> >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ > > > -- -- 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#8411) segfault on slapd 2.4.44
by mwtzzz＠gmail.com 24 Apr '16

24 Apr '16

OS: Linux rpi 4.1.13+ #826 PREEMPT Fri Nov 13 20:13:22 GMT 2015 armv6l GNU/Linux (gdb) info shared >From To Syms Read Shared Object Library 0xb6f344b8 0xb6f35a10 Yes (*) /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so 0xb6f16c04 0xb6f1b0bc Yes (*) /usr/lib/arm-linux-gnueabihf/libltdl.so.7 0xb6f0a928 0xb6f0b640 Yes (*) /lib/arm-linux-gnueabihf/libdl.so.2 0xb6de0dd0 0xb6ee4b74 Yes (*) /usr/lib/arm-linux-gnueabihf/libdb-5.1.so 0xb6da6558 0xb6db7504 Yes (*) /usr/lib/arm-linux-gnueabihf/libsasl2.so.2 0xb6d5f610 0xb6d90bac Yes (*) /usr/lib/arm-linux-gnueabihf/libssl.so.1.0.0 0xb6c35e80 0xb6d071c0 Yes (*) /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 0xb6bb8718 0xb6bbd1e8 Yes (*) /lib/arm-linux-gnueabihf/libcrypt.so.1 0xb6ba6444 0xb6bb273c Yes (*) /lib/arm-linux-gnueabihf/libresolv.so.2 0xb6b88eb0 0xb6b9691c Yes (*) /lib/arm-linux-gnueabihf/libpthread.so.0 0xb6a6a4a0 0xb6b583b0 Yes (*) /lib/arm-linux-gnueabihf/libc.so.6 0xb6f3e7c0 0xb6f57408 Yes (*) /lib/ld-linux-armhf.so.3 0xb6a38b38 0xb6a46f7c Yes (*) /lib/arm-linux-gnueabihf/libz.so.1 0xb6a1e450 0xb6a2e24c Yes (*) /lib/arm-linux-gnueabihf/libgcc_s.so.1 0xb6f25268 0xb6f298e0 Yes (*) /usr/lib/arm-linux-gnueabihf/sasl2/libntlm.so 0xb69ced8c 0xb69d0ae0 Yes (*) /usr/lib/arm-linux-gnueabihf/sasl2/libplain.so 0xb69c107c 0xb69c3bbc Yes (*) /usr/lib/arm-linux-gnueabihf/sasl2/libsasldb.so 0xb69ad400 0xb69b59e4 Yes (*) /usr/lib/arm-linux-gnueabihf/sasl2/libdigestmd5.so 0xb699fe04 0xb69a2004 Yes (*) /usr/lib/arm-linux-gnueabihf/sasl2/libcrammd5.so 0xb6993d5c 0xb69957f0 Yes (*) /usr/lib/arm-linux-gnueabihf/sasl2/libanonymous.so 0xb6987d50 0xb6989974 Yes (*) /usr/lib/arm-linux-gnueabihf/sasl2/liblogin.so 0xb6979e60 0xb697d8c0 Yes /usr/lib/ldap/slapd-sha2.so (*): Shared library is missing debugging information. (gdb) bt #0 0xb6f350a0 in memcpy () from /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so #1 0xb6c3f344 in SHA256_Update () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 #2 0xb697a69c in chk_ssha256 (scheme=0x19e27d4, passwd=0xa11caa20, cred=0x1a53468, text=0xa11cab98) at slapd-sha2.c:256 #3 0x00121f58 in lutil_passwd () #4 0x0006ec98 in slap_passwd_check () #5 0x000e4db8 in bdb_bind () #6 0x0005bbdc in fe_op_bind () #7 0x0005b568 in do_bind () #8 0x000403b8 in ?? () Cannot access memory at address 0x0 #9 0x000403b8 in ?? () Cannot access memory at address 0x0 Backtrace stopped: previous frame identical to this frame (corrupt stack?) On Sat, Apr 23, 2016 at 6:51 PM, Howard Chu <hyc(a)symas.com> wrote: > mwtzzz(a)gmail.com wrote: >> >> Full_Name: Michael Martinez >> Version: 2.4.44 >> OS: ubuntu wheezy > > > There is no such OS. > >> URL: >> Submission from: (NULL) (99.113.34.53) >> >> >> After upgrading from openldap-2.4.31 to 2.4.44 I'm getting segfaults >> anytime I >> run 'passwd', attempt to ssh into the box, etc. >> >> this is on raspberry pi (debian wheezy). >> >> Previously running the latest package 2.4.31. Then installed >> openldap-2.4.44 >> from source, did slapcat from the old version and slapadd to import it to >> the >> new version. Loads fine and can run simple commands like "id" for ldap >> users. >> But get core dump with password changes, ssh from other boxes, etc. >> A%A[Thread debugging using libthread_db enabled] >> Using host libthread_db library >> "/lib/arm-linux-gnueabihf/libthread_db.so.1". >> Core was generated by `/usr/local/openldap/libexec/slapd -f >> /etc/ldap/slapd.conf >> -F /ec/ldap/slapd.d'. >> Program terminated with signal 11, Segmentation fault. >> #0 0xb6f350a0 in memcpy () from >> /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so >> (gdb) > > > Please provide the full stack trace. > > Also output from "info shared". > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ -- --- Michael Martinez http://www.michael--martinez.com

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2016