openldap-bugs

openldap-bugs@openldap.org

21001 discussions

Re: (ITS#8085) Segfault on ppc64 caused by commit 6ad38fef3fe63ff86c1e6cff3c6330353b21cc24
by jsynacek＠redhat.com 19 Mar '15

19 Mar '15

jsynacek(a)redhat.com writes: > Full_Name: Jan Synacek > Version: master > OS: GNU/Linux > URL: > Submission from: (NULL) (213.175.37.10) > > > On PPC64, slapd segfaults on startup when using mdb as the backend. For some reason, this bug got submitted twice. Sorry for double posting. -- Jan Synacek Software Engineer, Red Hat

1 0

(ITS#8085) Segfault on ppc64 caused by commit 6ad38fef3fe63ff86c1e6cff3c6330353b21cc24
by jsynacek＠redhat.com 19 Mar '15

19 Mar '15

Full_Name: Jan Synacek Version: master OS: GNU/Linux URL: Submission from: (NULL) (213.175.37.10) On PPC64, slapd segfaults on startup when using mdb as the backend. Reproducer: 1) ./configure && make && make install STRIP="" 2) slapd -d1 -h "ldap:/// ldapi:///" -f slapd.conf $ cat slapd.conf include /etc/opldldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema allow bind_v2 pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args database mdb directory /var/lib/ldap/ suffix dc=foo,dc=bar,dc=com rootdn "cn=Manager,dc=foo,dc=bar,dc=com" # password is 'x' rootpw {SSHA}tOSmeQCcYIm1S9ujgpg2Km5rpUnR9dRBD%D There seems to be a program memory corruption, since the backtrace doesn't make any sense and valgrind reports "Illegal instruction". gdb --args -d1 -h "ldap:/// ldapi:///" -f slapd.conf ... (gdb) r ... Program received signal SIGSEGV, Segmentation fault. 0x000000001014b98c in 000006ae.plt_call.pthread_mutex_unlock@@GLIBC_2.3+0 () (gdb) bt #0 0x000000001014b98c in 000006ae.plt_call.pthread_mutex_unlock@@GLIBC_2.3+0 () #1 0x000000001014d79c in mdb_env_open (env=0x1034a4e0, path=0x102d5250 "/var/lib/ldap/", flags=536870912, mode=<value optimized out>) at ./../../../libraries/liblmdb/mdb.c:4540 #2 0x00000000100b91d4 in mdb_db_open (be=0x102b02c0, cr=0xfffffffe9a0) at init.c:174 #3 0x000000001003c130 in backend_startup_one (be=0x102b02c0, cr=0xfffffffe9a0) at backend.c:224 #4 0x000000001003c58c in backend_startup (be=0x102b02c0) at backend.c:330 #5 0x000000001005d650 in slap_startup (be=0x0) at init.c:220 #6 0x0000000010009b88 in main (argc=<value optimized out>, argv=<value optimized out>) at main.c:997 (gdb) up #1 0x000000001014d79c in mdb_env_open (env=0x1034a4e0, path=0x102d5250 "/var/lib/ldap/", flags=536870912, mode=<value optimized out>) at ./../../../libraries/liblmdb/mdb.c:4540 4540 env->me_path = strdup(path); I bisected the problem and the following commit is the problem: commit 6ad38fef3fe63ff86c1e6cff3c6330353b21cc24 Author: Howard Chu <hyc(a)openldap.org> Date: Wed Jan 14 19:05:17 2015 +0000 Fix typo in 45146ba21a9ee494e7058ca7a173fcc6b27df744 diff --git a/servers/slapd/schema_init.c b/servers/slapd/schema_init.c index 46d1c6d..08e733f 100644 --- a/servers/slapd/schema_init.c +++ b/servers/slapd/schema_init.c @@ -1826,7 +1826,7 @@ UTF8StringValidate( if( LDAP_UTF8_OFFSET( (char *)u ) != len ) return LDAP_INVALID_SYNTAX; } - if( u >= len ) { + if( u > end ) { return LDAP_INVALID_SYNTAX; } This problem is already present in 2.4.40, but absent in 2.4.39.

1 0

(ITS#8084) Segfault on ppc64 caused by commit 6ad38fef3fe63ff86c1e6cff3c6330353b21cc24
by jsynacek＠redhat.com 19 Mar '15

19 Mar '15

1 0

Re: (ITS#8062) Assertion 'IS_LEAF(mp)' failed in mdb_cursor_next()
by leo＠yuriev.ru 19 Mar '15

19 Mar '15

--001a113602ac48c9b00511a317b0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hm, in some case valgrind was reported as I noticed, sure 101%. Leonid 18.03.2015 23:12 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0= =B5=D0=BB=D1=8C "Howard Chu" <hyc(a)symas.com> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81= =D0=B0=D0=BB: > leo(a)yuriev.ru wrote: > >> As far as I remember this was fixed in ReOpenLDAP at January. >> Valgrind was reporting 'using uninitialized'. >> > > Not happening here. mdb_cursor_first() always initializes mc_ki. > >> >> Leonid. >> >> @@ -7301,6 +7551,7 @@ mdb_cursor_init(MDB_cursor *mc, MDB_txn *txn, >> MDB_dbi dbi, MDB_xcursor *mx) >> mc->mc_top =3D 0; >> mc->mc_pg[0] =3D 0; >> mc->mc_flags =3D 0; >> + mc->mc_ki[0] =3D 0; >> if (txn->mt_dbs[dbi].md_flags & MDB_DUPSORT) { >> mdb_tassert(txn, mx !=3D NULL); >> mc->mc_xcursor =3D mx; >> >> >> >> >> >> > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --001a113602ac48c9b00511a317b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hm, in some case valgrind was reported as I noticed, sure 10= 1%. Leonid <div class=3D"gmail_quote">18.03.2015 23:12 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7= =D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C "Howard Chu" <<a hr= ef=3D"mailto:hyc@symas.com">hyc(a)symas.com</a>> =D0=BD=D0=B0=D0=BF=D0=B8= =D1=81=D0=B0=D0=BB: <blockquote class=3D"gmail_quot= e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">= <a href=3D"mailto:leo@yuriev.ru" target=3D"_blank">leo(a)yuriev.ru</a> wrote:= <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> As far as I remember this was fixed in ReOpenLDAP at January. Valgrind was reporting 'using uninitialized'. </blockquote> Not happening here. mdb_cursor_first() always initializes mc_ki. <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Leonid. @@ -7301,6 +7551,7 @@ mdb_cursor_init(MDB_cursor *mc, MDB_txn *txn, MDB_dbi dbi, MDB_xcursor *mx) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mc->mc_top =3D 0; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mc->mc_pg[0] =3D 0; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mc->mc_flags =3D 0; +=C2=A0 =C2=A0 =C2=A0 =C2=A0mc->mc_ki[0] =3D 0; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (txn->mt_dbs[dbi].md_flags & M= DB_DUPSORT) { =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mdb_tassert(= txn, mx !=3D NULL); =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mc->mc_xc= ursor =3D mx; </blockquote> -- =C2=A0 -- Howard Chu =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= http://www.symas.com" target=3D"_blank">http://www.symas.com</a> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= sun.com/hyc/" target=3D"_blank">http://highlandsun.com/hyc/</a> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" target=3D"_blank">http://www.openldap.org/project/</a> </blockquote></div> --001a113602ac48c9b00511a317b0--

1 0

Re: (ITS#8081) syncprov crash in syncprov_op_mod
by leo＠yuriev.ru 19 Mar '15

19 Mar '15

--047d7b87466456cd650511a30230 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Howard, I don't submit this path or so on. But you can see the bugs and fix it in openldap. Leonid 18.03.2015 22:17 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0= =B5=D0=BB=D1=8C "Howard Chu" <hyc(a)symas.com> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81= =D0=B0=D0=BB: > leo(a)yuriev.ru wrote: > >> Fixed in ReOpenLDAP week ago. >> https://github.com/ReOpen/ReOpenLDAP/commit/ >> 6de52172bc0f8309dd00c329452213d51e5573a9 >> > > Leo: if you intend for this patch to be adopted here, please attach the > IPR notice as documented > > http://www.openldap.org/devel/contributing.html > > Note that, as written, your patch is unacceptable as it violates the "one > functional change per patch" condition. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --047d7b87466456cd650511a30230 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Howard, I don't submit this path or so on. But you can s= ee the bugs and fix it in openldap. Leonid <div class=3D"gmail_quote">18.03.2015 22:17 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7= =D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C "Howard Chu" <<a hr= ef=3D"mailto:hyc@symas.com">hyc(a)symas.com</a>> =D0=BD=D0=B0=D0=BF=D0=B8= =D1=81=D0=B0=D0=BB: <blockquote class=3D"gmail_quot= e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">= <a href=3D"mailto:leo@yuriev.ru" target=3D"_blank">leo(a)yuriev.ru</a> wrote:= <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Fixed in ReOpenLDAP week ago. <a href=3D"https://github.com/ReOpen/ReOpenLDAP/commit/6de52172bc0f8309dd00= c329452213d51e5573a9" target=3D"_blank">https://github.com/ReOpen/Re= OpenLDAP/commit/6de52172bc0f8309dd00c329452213d51e5573a9</a><= br> </blockquote> Leo: if you intend for this patch to be adopted here, please attach the IPR= notice as documented <a href=3D"http://www.openldap.org/devel/contributing.html" target=3D"_blan= k">http://www.openldap.org/devel/contributing.html</a> Note that, as written, your patch is unacceptable as it violates the "= one functional change per patch" condition. -- =C2=A0 -- Howard Chu =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= http://www.symas.com" target=3D"_blank">http://www.symas.com</a> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= sun.com/hyc/" target=3D"_blank">http://highlandsun.com/hyc/</a> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" target=3D"_blank">http://www.openldap.org/project/</a> </blockquote></div> --047d7b87466456cd650511a30230--

1 0

Re: (ITS#8081) syncprov crash in syncprov_op_mod
by ryan＠nardis.ca 18 Mar '15

18 Mar '15

On Wed, Mar 18, 2015 at 05:06:33AM +0000, ryan(a)nardis.ca wrote: >I get the following crash on master and RE24. not every time, but most times. > >Program received signal SIGSEGV, Segmentation fault. >[Switching to Thread 0x7fffe6ffe700 (LWP 25923)] >0x0000000000511d45 in syncprov_op_mod (op=0x7fffd41024a0, rs=0x7fffe6ffdae0) at >syncprov.c:2129 >2129 if ( m2->mi_op->o_threadctx == op->o_threadctx ) { Same testcase, different crash: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffecde1700 (LWP 1747)] 0x000000000051ae5e in syncprov_op_cleanup (op=0x7fffe0000aa0, rs=0x7fffecde0ac0) at syncprov.c:1418 1418 mt->mt_mods = mt->mt_mods->mi_next; (gdb) bt #0 0x000000000051ae5e in syncprov_op_cleanup (op=0x7fffe0000aa0, rs=0x7fffecde0ac0) at syncprov.c:1418 #1 0x00000000004417f3 in slap_cleanup_play (op=0x7fffe0000aa0, rs=0x7fffecde0ac0) at result.c:567 #2 0x0000000000441fac in send_ldap_response (op=0x7fffe0000aa0, rs=0x7fffecde0ac0) at result.c:759 #3 0x0000000000442793 in slap_send_ldap_result (op=0x7fffe0000aa0, rs=0x7fffecde0ac0) at result.c:886 #4 0x00000000004e472a in mdb_modify (op=0x7fffe0000aa0, rs=0x7fffecde0ac0) at modify.c:672 #5 0x00000000004baadd in overlay_op_walk (op=0x7fffe0000aa0, rs=0x7fffecde0ac0, which=op_modify, oi=0x8aae60, on=0x0) at backover.c:696 #6 0x00000000004bad01 in over_op_func (op=0x7fffe0000aa0, rs=0x7fffecde0ac0, which=op_modify) at backover.c:749 #7 0x00000000004bae35 in over_op_modify (op=0x7fffe0000aa0, rs=0x7fffecde0ac0) at backover.c:788 #8 0x000000000044bacb in fe_op_modify (op=0x7fffe0000aa0, rs=0x7fffecde0ac0) at modify.c:303 #9 0x000000000044b37e in do_modify (op=0x7fffe0000aa0, rs=0x7fffecde0ac0) at modify.c:177 #10 0x000000000042bdf3 in connection_operation (ctx=0x7fffecde0bf0, arg_v=0x7fffe0000aa0) at connection.c:1134 #11 0x000000000042c3a3 in connection_read_thread (ctx=0x7fffecde0bf0, argv=0xb) at connection.c:1280 #12 0x000000000053772e in ldap_int_thread_pool_wrapper (xpool=0x883b40) at tpool.c:958 #13 0x00007ffff77ad0a4 in start_thread (arg=0x7fffecde1700) at pthread_create.c:309 #14 0x00007ffff74e204d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Looks like at this point mt either points to garbage, or is itself garbage. Reverting 8eb9aa7d resolves both crashes.

1 0

Re: (ITS#8080) nssov allows users to change anyone's password
by hyc＠symas.com 18 Mar '15

18 Mar '15

Ryan Tandy wrote: > On Mon, Mar 16, 2015 at 05:44:50PM +0000, hyc(a)symas.com wrote: >>> ftp://ftp.openldap.org/incoming/20150315_rtandy_nssov-require-old-password-… >>> >> >> I think this patch is a bit off; it prevents root from supplying the >> old pwd. (Which it must do if changing its own.) > > I don't follow, sorry. If root is the pwdmgr, then the current code > already omits the old password, even if the request includes it, and > passwd_extop() seems to be fine with that. True. > And if root auths as a DN > different from the pwdmgr DN, then it's a normal self-change and the old > password is checked. Did I get some part of that wrong? > > You could argue that we should always check the old password if > provided, even when working as pwdmgr. I would agree with that. It's not > what the current code does, though. Right, I think if we're in here anyway we should fix that. > And on my systems at least, passwd running as root never asks for the > current password, even when changing root's own password. (Of course > that might be different elsewhere.) Admittedly, it's been a long time since I've changed a root password, since I just use ssh keys most of the time. -- -- 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#8062) Assertion 'IS_LEAF(mp)' failed in mdb_cursor_next()
by hyc＠symas.com 18 Mar '15

18 Mar '15

leo(a)yuriev.ru wrote: > As far as I remember this was fixed in ReOpenLDAP at January. > Valgrind was reporting 'using uninitialized'. Not happening here. mdb_cursor_first() always initializes mc_ki. > > Leonid. > > @@ -7301,6 +7551,7 @@ mdb_cursor_init(MDB_cursor *mc, MDB_txn *txn, > MDB_dbi dbi, MDB_xcursor *mx) > mc->mc_top = 0; > mc->mc_pg[0] = 0; > mc->mc_flags = 0; > + mc->mc_ki[0] = 0; > if (txn->mt_dbs[dbi].md_flags & MDB_DUPSORT) { > mdb_tassert(txn, mx != NULL); > mc->mc_xcursor = mx; > > > > > -- -- 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#8081) syncprov crash in syncprov_op_mod
by hyc＠symas.com 18 Mar '15

18 Mar '15

leo(a)yuriev.ru wrote: > Fixed in ReOpenLDAP week ago. > https://github.com/ReOpen/ReOpenLDAP/commit/6de52172bc0f8309dd00c329452213d… Leo: if you intend for this patch to be adopted here, please attach the IPR notice as documented http://www.openldap.org/devel/contributing.html Note that, as written, your patch is unacceptable as it violates the "one functional change per patch" condition. -- -- 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#8082) slapd leaks memory - using clang to do static analysis
by hyc＠symas.com 18 Mar '15

18 Mar '15

ludovic(a)hirlimann.net wrote: > Full_Name: Ludovic Hirlimann > Version: trunk > OS: Fedora 21 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2a01:e34:ed45:8a70:eab1:fcff:fede:413) Thanks for the report but this "leak" is entirely benign, the code is only executed once at startup and leaks don't accumulate during runtime. We'll fix it but it's far from high priority. > > [ludo@Oulanl openldap]$ ASAN_SYMBOLIZER_PATH=/usr/bin/llvm-symbolizer > ./servers/slapd/slapcat > 550969a1 could not stat config file "/usr/local/etc/openldap/slapd.conf": No > such file or directory (2) > slapcat: bad configuration file! > > ================================================================= > ==11688==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 4104 byte(s) in 1 object(s) allocated from: > #0 0x4b2b50 in calloc (/home/ludo/openldap/servers/slapd/slapd+0x4b2b50) > #1 0x7b33cd in ber_memcalloc_x > /home/ludo/openldap/libraries/liblber/memory.c:283:9 > #2 0x5703c3 in ch_calloc > /home/ludo/openldap/servers/slapd/ch_malloc.c:104:23 > #3 0x5005e7 in init_config_argv > /home/ludo/openldap/servers/slapd/config.cA1A118:12 > #4 0x505491 in read_config_file > /home/ludo/openldap/servers/slapd/config.c:727:2 > #5 0x4d4771 in read_config > /home/ludo/openldap/servers/slapd/bconfig.c:4485:7 > #6 0x651804 in slap_tool_init > /home/ludo/openldap/servers/slapd/slapcomm.c.c:672:7 > #7 0x64fb63 in slapcat /home/ludo/openldap/servers/slapd/slapcat.c:53:2 > #8 0x4d1b76 in main /home/ludo/openldap/servers/slapd/main.c:411:10 > #9 0x7fa949271fdf in __libc_start_main (/lib64/libc.so.6+0x1ffdf) > > SUMMARY: AddressSanitizer: 4104 byte(s) leaked in 1 allocation(s). > > > -- -- 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs