openldap-bugs October 2014

openldap-bugs@openldap.org

14 participants
76 discussions

Re: (ITS#7968) SIGSEGV shortly after reconnection performed by syncrepl due to synchronization conflicts
by hyc＠symas.com 15 Oct '14

15 Oct '14

leo(a)yuriev.ru wrote: > Full_Name: Leonid Yuriev > Version: 2.4.40 > OS: RHEL7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (31.130.36.33) > > > Currently there is a couple of backtraces only. > This is the result of a stress test of replication in the presence of > sync-conflicts after a "split brain" case. > No any network troubles (just a loopback connections). Looks like it's accessing freed memory, and it's also related to Abandon processing. You might be running into ITS#7967 as well. If you can reproduce this, try running with a malloc debugger. > > ** Signal 11 (Segmentation fault), address is 0x797a from 0x50e8bd > (0) /opt/openldap.devel/libexec/slapd() [0x50e8bd]: syncprov_op_abandon > /home/ly/Projects/openldap.git/servers/slapd/overlays/syncprov.c:1134 > (1) /opt/openldap.devel/libexec/slapd() [0x48b31a]: overlay_op_walk > /home/ly/Projects/openldap.git/servers/slapd/backover.c:662 > (2) /opt/openldap.devel/libexec/slapd() [0x48b4c1]: over_op_func > /home/ly/Projects/openldap.git/servers/slapd/backover.c:724 > (3) /opt/openldap.devel/libexec/slapd() [0x4429a7]: fe_op_abandon > /home/ly/Projects/openldap.git/servers/slapd/abandon.c:134 (discriminator 2) > (4) /opt/openldap.devel/libexec/slapd() [0x42283c]: connection_abandon > /home/ly/Projects/openldap.git/servers/slapd/connection.c:740 (discriminator 3) > (5) /opt/openldap.devel/libexec/slapd() [0x424509]: connection_closing > /home/ly/Projects/openldap.git/servers/slapd/connection.c:829 > (6) /opt/openldap.devel/libexec/slapd() [0x4250ef]: connection_read > /home/ly/Projects/openldap.git/servers/slapd/connection.c:1477 > connection_read_thread > /home/ly/Projects/openldap.git/servers/slapd/connection.c:1284 > (7) /opt/openldap.devel/lib/libldap_r-2.4.so.2(+0x10cf2) [0x7f8c6de89cf2]: ?? > > *** Signal 11 (Segmentation fault), address is 0x7f7a1e1c5000 from > 0x7f7a1eebfb54 > (0) /lib/x86_64-linux-gnu/libc.so.6(+0x98b54) [0x7f7a1eebfb54]: ????:0 > (1) /opt/openldap.devel/libexec/slapd() [0x4afa7d]: mdb_search > /home/ly/Projects/openldap.git/servers/slapd/back-mdb/search.c:987 > (discriminator 3) > (2) /opt/openldap.devel/libexec/slapd() [0x48b356]: 543edda2 overlay_op_walk > /home/ly/Projects/openldap.git/servers/slapd/backover.c:674 > (3) /opt/openldap.devel/libexec/slapd() [0x48b4c1]: over_op_func > /home/ly/Projects/openldap.git/servers/slapd/backover.c:724 > (4) /opt/openldap.devel/libexec/slapd() [0x427201]: fe_op_search > /home/ly/Projects/openldap.git/servers/slapd/search.c:402 > (5) /opt/openldap.devel/libexec/slapd() [0x426c0c]: do_search > /home/ly/Projects/openldap.git/servers/slapd/search.c:247 > (6) /opt/openld.d.devel/libexec/slapd() [0x424b54]: connection_operation > /home/ly/Projects/openldap.git/servers/slapd/connection.c:1158 > (7) /opt/openldap.devel/libexec/slapd() [0x42526c]: connection_read_thread > /home/ly/Projects/openldap.git/servers/slapd/connection.c:1291 > (8) /opt/openldap.devel/lib/libldap_r-2.4.so.2(+0x10cf2) [0x7f7a1f629cf2]: ?? > > -- -- 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#7968) SIGSEGV shortly after reconnection performed by syncrepl due to synchronization conflicts
by leo＠yuriev.ru 15 Oct '14

15 Oct '14

One more case *** Signal 11 (Segmentation fault), address is 0xb from 0x442f07 (0) /opt/openldap.devel/libexec/slapd() [0x442f07]: test_filter /home/ly/Projects/openldap.git/servers/slapd/filterentry.c:69 (1) /opt/openldap.devel/libexec/slapd() [0x514721]: syncprov_matchops /home/ly/Projects/openldap.git/servers/slapd/overlays/syncprov.c:1316 (2) /opt/openldap.devel/libexec/slapd() [0x514b83]: syncprov_op_mod /home/ly/Projects/openldap.git/servers/slapd/overlays/syncprov.c:2145 (3) /opt/openldap.devel/libexec/slapd() [0x48b31a]: overlay_op_walk /home/ly/Projects/openldap.git/servers/slapd/backover.c:662 (4) /opt/openldap.devel/libexec/slapd() [0x48b4c1]: over_op_func /home/ly/Projects/openldap.git/servers/slapd/backover.c:724 (5) /opt/openldap.devel/libexec/slapd() [0x4811a6]: syncrepl_entry /home/ly/Projects/openldap.git/servers/slapd/syncrepl.c:3177 do_syncrep2 /home/ly/Projects/openldap.git/servers/slapd/syncrepl.c:1024 (6) /opt/openldap.devel/libexec/slapd() [0x4844b2]: do_syncrepl /home/ly/Projects/openldap.git/servers/slapd/syncrepl.c:1539 (7) /opt/openldap.devel/lib/libldap_r-2.4.so.2(+0x10cf2) [0x7f398891acf2]: ??

1 0

(ITS#7968) SIGSEGV shortly after reconnection performed by syncrepl due to synchronization conflicts
by leo＠yuriev.ru 15 Oct '14

15 Oct '14

Full_Name: Leonid Yuriev Version: 2.4.40 OS: RHEL7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (31.130.36.33) Currently there is a couple of backtraces only. This is the result of a stress test of replication in the presence of sync-conflicts after a "split brain" case. No any network troubles (just a loopback connections). ** Signal 11 (Segmentation fault), address is 0x797a from 0x50e8bd (0) /opt/openldap.devel/libexec/slapd() [0x50e8bd]: syncprov_op_abandon /home/ly/Projects/openldap.git/servers/slapd/overlays/syncprov.c:1134 (1) /opt/openldap.devel/libexec/slapd() [0x48b31a]: overlay_op_walk /home/ly/Projects/openldap.git/servers/slapd/backover.c:662 (2) /opt/openldap.devel/libexec/slapd() [0x48b4c1]: over_op_func /home/ly/Projects/openldap.git/servers/slapd/backover.c:724 (3) /opt/openldap.devel/libexec/slapd() [0x4429a7]: fe_op_abandon /home/ly/Projects/openldap.git/servers/slapd/abandon.c:134 (discriminator 2) (4) /opt/openldap.devel/libexec/slapd() [0x42283c]: connection_abandon /home/ly/Projects/openldap.git/servers/slapd/connection.c:740 (discriminator 3) (5) /opt/openldap.devel/libexec/slapd() [0x424509]: connection_closing /home/ly/Projects/openldap.git/servers/slapd/connection.c:829 (6) /opt/openldap.devel/libexec/slapd() [0x4250ef]: connection_read /home/ly/Projects/openldap.git/servers/slapd/connection.c:1477 connection_read_thread /home/ly/Projects/openldap.git/servers/slapd/connection.c:1284 (7) /opt/openldap.devel/lib/libldap_r-2.4.so.2(+0x10cf2) [0x7f8c6de89cf2]: ?? *** Signal 11 (Segmentation fault), address is 0x7f7a1e1c5000 from 0x7f7a1eebfb54 (0) /lib/x86_64-linux-gnu/libc.so.6(+0x98b54) [0x7f7a1eebfb54]: ????:0 (1) /opt/openldap.devel/libexec/slapd() [0x4afa7d]: mdb_search /home/ly/Projects/openldap.git/servers/slapd/back-mdb/search.c:987 (discriminator 3) (2) /opt/openldap.devel/libexec/slapd() [0x48b356]: 543edda2 overlay_op_walk /home/ly/Projects/openldap.git/servers/slapd/backover.c:674 (3) /opt/openldap.devel/libexec/slapd() [0x48b4c1]: over_op_func /home/ly/Projects/openldap.git/servers/slapd/backover.c:724 (4) /opt/openldap.devel/libexec/slapd() [0x427201]: fe_op_search /home/ly/Projects/openldap.git/servers/slapd/search.c:402 (5) /opt/openldap.devel/libexec/slapd() [0x426c0c]: do_search /home/ly/Projects/openldap.git/servers/slapd/search.c:247 (6) /opt/openld.d.devel/libexec/slapd() [0x424b54]: connection_operation /home/ly/Projects/openldap.git/servers/slapd/connection.c:1158 (7) /opt/openldap.devel/libexec/slapd() [0x42526c]: connection_read_thread /home/ly/Projects/openldap.git/servers/slapd/connection.c:1291 (8) /opt/openldap.devel/lib/libldap_r-2.4.so.2(+0x10cf2) [0x7f7a1f629cf2]: ??

1 0

(ITS#7967) back-meta crash sending abandon after error
by hyc＠openldap.org 15 Oct '14

15 Oct '14

Full_Name: Howard Chu Version: 2.4.40 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.235.15.202) Submitted by: hyc The patch in ITS#7712 breaks ldap_abandon processing. In particular, releasing the req_mutex makes it possible for ldap_free_request() to be called twice on the same request. A new fix is being tested.

1 0

Re: (ITS#7966) OpenLDAP server 2.4.40 crashes with rwm and ppolicy overlay during bind
by konrad.windszus＠netcentric.biz 14 Oct '14

14 Oct '14

We use two backends 1) Is leveraging ppolicy with an hdb backend 2) Is leveraging rwm with a relay backend (relaying to 1) with a = different suffix Therefore we cannot influence the order. Modifying the loading order of = the overlays did result in exactly the same stacktrace.=

1 0

Re: (ITS#7966) OpenLDAP server 2.4.40 crashes with rwm and ppolicy overlay during bind
by michael＠stroeder.com 14 Oct '14

14 Oct '14

On Tue, 14 Oct 2014 15:31:25 +0000 konrad.windszus(a)netcentric.biz wrote > As soon as the overlay ppolicy is disabled, the crash is gone. Can you also please try whether the order of slapo-rwm and slapo-ppolicy makes any difference? Ciao, Michael.

1 0

(ITS#7966) OpenLDAP server 2.4.40 crashes with rwm and ppolicy overlay during bind
by konrad.windszus＠netcentric.biz 14 Oct '14

14 Oct '14

Full_Name: Konrad Windszus Version: 2.4.40 OS: CentOS 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.61.79.222) Running the overlays ppolicy and rwm on OpenLDAP 2.4.40 (RPM from http://ltb-project.org/) and executing a bind request on the mapped area leads to a segmentation fault. This is the stacktrace from GDB Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ff1f61a4700 (LWP 22660)] 0x0000000000000012 in ?? () (gdb) bt #0 0x0000000000000012 in ?? () #1 0x0000000000505dc0 in hdb_reader_get (op=op@entry=0x7ff1ec000980, env=0x11fa840, txn=txn@entry=0x7ff1f61a30e0) at cache.c:1673 #2 0x000000000050e5ea in hdb_entry_get (op=0x7ff1ec000980, ndn=0x7ff1ec0009b8, oc=0x0, at=0x0, rw=0, ent=0x7ff1f61a3398) at id2entry.c:349 #3 0x00000000004a4cba in overlay_entry_get_ov (op=0x7ff1ec000980, dn=0x7fecec0009b8, oc=0x0, ad=0x0, rw=0, e=0x7ff1f61a3398, on=<optimized out>) at backover.c:364 #4 0x00000000004a4d27 in over_entry_get_rw (op=<optimized out>, dn=<optimized out>, oc=<optimized out>, ad=<optimized out>, rw=<optimized out>, e=<optimized out>) at backover.c:396 #5 0x00000000005528a7 in ppolicy_bind_response (op=0x7ff1ec000980, rs=0x7ff1f61a39a0) at ppolicy.c:924 #6 0x000000000044edb6 in slap_response_play (op=op@entry=0x7ff1ec000980, rs=rs@entry=0x7ff1f61a39a0) at result.c:508 #7 0x000000000044f2c7 in send_ldap_response (op=op@entry=0x7ff1ec000980, rs=rs@entry=0x7ff1f61a39a0) at result.c:583 #8 0x000000000044fc62 in slap_send_ldap_result (op=0x7ff1ec000980, rs=0x7ff1f61a39a0) at result.c:861 #9 0x000000000045c239 in fe_op_bind_success (op=op@entry=0x7ff1ec000980, rs=rs@entry=0x7ff1f61a39a0) at bind.c:441 #10 0x000000000045c8fd in fe_op_bind (op=0x7ff1ec000980, rs=0x7ff1f61a39a0) at bind.c:386 #11 0x000000000045c041 in do_bind (op=0x7ff1ec000980, rs=0x7ff1f61a39a0) at bind.c:205 #12 0x000000000044032e in connection_operation (ctx=ctx@entry=0x7ff1f61a3ad0, arg_v=arg_v@entry=0x7ff1ec000980) at connection.c:1155 #13 0x000000000044060a in connection_read_thread (ctx=0x7ff1f61a3ad0, argv=0xc) at connection.c:1291 #14 0x000000000058da59 in ldap_int_thread_pool_wrapper (xpool=0x113cee0) at tpool.c:688 #15 0x00007ff1fab7ddf3 in start_thread (arg=0x7ff1f61a4700) at pthread_create.c:308 #16 0x00007ff1f99e201d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 As soon as the overlay ppolicy is disabled, the crash is gone.

1 0

(ITS#7963)
by kenel.bastoon＠gmail.com 14 Oct '14

14 Oct '14

--001a113ad9f09d6b280505632e3d Content-Type: text/plain; charset=UTF-8 Thank you for your reply. I will follow your suggestion. As my case is not urgent, I'll send comments to ITS#6664 when I'll have time to test more in depth. Regards --001a113ad9f09d6b280505632e3d Content-Type: text/html; charset=UTF-8 <div dir="ltr">Thank you for your reply.<div><br></div><div>I will follow your suggestion. As my case is not urgent, I'll send comments to ITS#6664 when I'll have time to test more in depth.</div><div><br></div><div>Regards</div></div> --001a113ad9f09d6b280505632e3d--

1 0

Re: (ITS#7948) mdb_copy insecure permissions
by hyc＠symas.com 14 Oct '14

14 Oct '14

geert(a)hendrickx.be wrote: > Full_Name: Geert Hendrickx > Version: 2.4.39 > OS: centos6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.123.14.2) > > > mdb_copy creates a copy using the default umask. This usually leads to insecure > (world readable) copies, as typically an LDAP databse is 600 owned by some > unprivileged ldap user. The mode has changed to 0600 as of commit 58ddb5527bd4868bb7017cfe2051bc2e24bcf5a8 -- -- 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#7965) heap corruption due to returning a reference to the local variable
by hyc＠symas.com 14 Oct '14

14 Oct '14

Леонид Юрьев wrote: > The attached files is derived from OpenLDAP Software. All of the modifications > to OpenLDAP Software represented in the following patch(es) were developed by > Peter-Service LLC, Moscow, Russia. Peter-Service LLC has not assigned rights > and/or interest in this work to any party. I, Leonid Yuriev am authorized by > Peter-Service LLC, my employer, to release this work under the following terms. > > Peter-Service LLC hereby places the following modifications to OpenLDAP Software > (and only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose with or > without attribution and/or other notice. Thanks, committed to git master. > https://github.com/leo-yuriev/openldap-lmdb-challenge/commit/1d29214f60300c… > > Author: Leo Yuriev <leo(a)yuriev.ru> > Date: 2014-10-14 14:49:25 +0400 > > BUGFIX - lmdb-backend: heap corruption due to returning a > reference to the local variable. > > diff --git a/servers/slapd/back-mdb/dn2id.c b/servers/slapd/back-mdb/dn2id.c > index 06e6ad3..41c4758 100644 > --- a/servers/slapd/back-mdb/dn2id.c > +++ b/servers/slapd/back-mdb/dn2id.c > @@ -346,7 +346,7 @@ mdb_dn2id( > cursor = mc; > } else { > rc = mdb_cursor_open( txn, dbi, &cursor ); > - if ( rc ) return rc; > + if ( rc ) goto done; > } > > for (;;) { > @@ -470,7 +470,7 @@ mdb_dn2sups( > key.mv_size = sizeof(ID); > > rc = mdb_cursor_open( txn, dbi, &cursor ); > - if ( rc ) return rc; > + if ( rc ) goto done; > > for (;;) { > key.mv_data = &pid; > -- -- 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2014