- openldap-bugs - openldap.org

[Bug 9135] mdb index corruption during legitimate delete
by openldap-its＠openldap.org 13 Mar '20

13 Mar '20

https://bugs.openldap.org/show_bug.cgi?id=9135 quanah(a)openldap.org changed: What |Removed |Added ---------------------------------------------------------------------------- Component|slapd |backends CC| |openldap-bugs(a)openldap.org -- You are receiving this mail because: You are watching someone on the CC list of the bug.

1 0

[Bug 9136] mdb index degradation failure
by openldap-its＠openldap.org 13 Mar '20

13 Mar '20

https://bugs.openldap.org/show_bug.cgi?id=9136 quanah(a)openldap.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |openldap-bugs(a)openldap.org Component|slapd |backends -- You are receiving this mail because: You are watching someone on the CC list of the bug.

1 0

[Bug 9125] [regression] back-ldap does not respect --without-tls
by openldap-its＠openldap.org 13 Mar '20

13 Mar '20

https://bugs.openldap.org/show_bug.cgi?id=9125 quanah(a)openldap.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |openldap-bugs(a)openldap.org Component|slapd |backends -- You are receiving this mail because: You are watching someone on the CC list of the bug.

1 0

[Bug 9099] LMDB: range delete
by openldap-its＠openldap.org 13 Mar '20

13 Mar '20

https://bugs.openldap.org/show_bug.cgi?id=9099 quanah(a)openldap.org changed: What |Removed |Added ---------------------------------------------------------------------------- Component|slapd |liblmdb CC| |openldap-bugs(a)openldap.org Product|OpenLDAP |LMDB -- You are receiving this mail because: You are watching someone on the CC list of the bug.

1 0

[Bug 9176] libldap support for TLSv1.3 Encrypted SNI
by openldap-its＠openldap.org 13 Mar '20

13 Mar '20

https://bugs.openldap.org/show_bug.cgi?id=9176 quanah(a)openldap.org changed: What |Removed |Added ---------------------------------------------------------------------------- Component|slapd |libraries CC| |openldap-bugs(a)openldap.org -- You are receiving this mail because: You are watching someone on the CC list of the bug.

1 0

[Bug 8913] Add meson build system to lmdb
by openldap-its＠openldap.org 13 Mar '20

13 Mar '20

https://bugs.openldap.org/show_bug.cgi?id=8913 quanah(a)openldap.org changed: What |Removed |Added ---------------------------------------------------------------------------- Component|slapd |liblmdb Product|OpenLDAP |LMDB CC| |openldap-bugs(a)openldap.org -- You are receiving this mail because: You are watching someone on the CC list of the bug.

1 0

[Bug 8883] add custom attribute
by openldap-its＠openldap.org 13 Mar '20

13 Mar '20

https://bugs.openldap.org/show_bug.cgi?id=8883 quanah(a)openldap.org changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|SECURITY: add custom |add custom attribute |attribute | -- You are receiving this mail because: You are watching someone on the CC list of the bug.

1 0

[Bug 8883] SECURITY: add custom attribute
by openldap-its＠openldap.org 13 Mar '20

13 Mar '20

https://bugs.openldap.org/show_bug.cgi?id=8883 quanah(a)openldap.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are watching someone on the CC list of the bug.

1 0

[Bug 8883] SECURITY: add custom attribute
by openldap-its＠openldap.org 13 Mar '20

13 Mar '20

1 0

Re: (ITS#9182) slapd crash with invalid pcache config
by ryan＠nardis.ca 11 Mar '20

11 Mar '20

On Wed, Mar 11, 2020 at 07:18:22PM +0000, Howard Chu wrote: >Fixed in git master Confirmed fixed, thanks!

1 0

Re: (ITS#9182) slapd crash with invalid pcache config
by hyc＠symas.com 11 Mar '20

11 Mar '20

ryan(a)openldap.org wrote: > Full_Name: Ryan Tandy > Version: RE24 > OS: Debian > URL: > Submission from: (NULL) (70.66.128.207) > Submitted by: ryan > > > Reported in IRC #openldap by user Dragnell, reproduced by me on current RE24. > > Configure slapd like so: > Fixed in git 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

Re: (ITS#9182) slapd crash with invalid pcache config
by ryan＠nardis.ca 11 Mar '20

11 Mar '20

==24838== Thread 3: ==24838== Invalid read of size 8 ==24838== at 0x13FCD3: backend_stopdown_one (backend.c:425) ==24838== by 0x1DF97A: pcache_db_destroy (pcache.c:4899) ==24838== by 0x19AD46: overlay_destroy_one (backover.c:1150) ==24838== by 0x124A10: config_add_internal.isra.16 (bconfig.c:5318) ==24838== by 0x125323: config_back_add (bconfig.c:5457) ==24838== by 0x13968C: fe_op_add (add.c:334) ==24838== by 0x13A49D: do_add (add.c:194) ==24838== by 0x1332BB: connection_operation (connection.c:1175) ==24838== by 0x133D52: connection_read_thread (connection.c:1311) ==24838== by 0x1F8238: ldap_int_thread_pool_wrapper.part.0 (tpool.c:696) ==24838== by 0x486BFA2: start_thread (pthread_create.c:486) ==24838== by 0x497E4CE: clone (clone.S:95) ==24838== Address 0x4ecec10 is 0 bytes inside a block of size 16 free'd ==24838== at 0x48369AB: free (vg_replace_malloc.c:530) ==24838== by 0x13FD34: backend_stopdown_one (backend.c:434) ==24838== by 0x1DF97A: pcache_db_destroy (pcache.c:4899) ==24838== by 0x19AD46: overlay_destroy_one (backover.c:1150) ==24838== by 0x124A10: config_add_internal.isra.16 (bconfig.c:5318) ==24838== by 0x125323: config_back_add (bconfig.c:5457) ==24838== by 0x13968C: fe_op_add (add.c:334) ==24838== by 0x13A49D: do_add (add.c:194) ==24838== by 0x1332BB: connection_operation (connection.c:1175) ==24838== by 0x133D52: connection_read_thread (connection.c:1311) ==24838== by 0x1F8238: ldap_int_thread_pool_wrapper.part.0 (tpool.c:696) ==24838== by 0x486BFA2: start_thread (pthread_create.c:486) ==24838== Block was alloc'd at ==24838== at 0x4837B65: calloc (vg_replace_malloc.c:752) ==24838== by 0x21FE44: ber_memcalloc_x (memory.c:283) ==24838== by 0x14DB62: ch_calloc (ch_malloc.c:104) ==24838== by 0x13F661: backend_startup_one (backend.c:200) ==24838== by 0x13F98A: backend_startup (backend.c:325) ==24838== by 0x15F920: slap_startup (init.c:219) ==24838== by 0x119D22: main (main.c:1005) ==24838== ==24838== Invalid free() / delete / delete[] / realloc() ==24838== at 0x48369AB: free (vg_replace_malloc.c:530) ==24838== by 0x13FD34: backend_stopdown_one (backend.c:434) ==24838== by 0x1DF97A: pcache_db_destroy (pcache.c:4899) ==24838== by 0x19AD46: overlay_destroy_one (backover.c:1150) ==24838== by 0x124A10: config_add_internal.isra.16 (bconfig.c:5318) ==24838== by 0x125323: config_back_add (bconfig.c:5457) ==24838== by 0x13968C: fe_op_add (add.c:334) ==24838== by 0x13A49D: do_add (add.c:194) ==24838== by 0x1332BB: connection_operation (connection.c:1175) ==24838== by 0x133D52: connection_read_thread (connection.c:1311) ==24838== by 0x1F8238: ldap_int_thread_pool_wrapper.part.0 (tpool.c:696) ==24838== by 0x486BFA2: start_thread (pthread_create.c:486) ==24838== Address 0x4ecec10 is 0 bytes inside a block of size 16 free'd ==24838== at 0x48369AB: free (vg_replace_malloc.c:530) ==24838== by 0x13FD34: backend_stopdown_one (backend.c:434) ==24838== by 0x1DF97A: pcache_db_destroy (pcache.c:4899) ==24838== by 0x19AD46: overlay_destroy_one (backover.c:1150) ==24838== by 0x124A10: config_add_internal.isra.16 (bconfig.c:5318) ==24838== by 0x125323: config_back_add (bconfig.c:5457) ==24838== by 0x13968C: fe_op_add (add.c:334) ==24838== by 0x13A49D: do_add (add.c:194) ==24838== by 0x1332BB: connection_operation (connection.c:1175) ==24838== by 0x133D52: connection_read_thread (connection.c:1311) ==24838== by 0x1F8238: ldap_int_thread_pool_wrapper.part.0 (tpool.c:696) ==24838== by 0x486BFA2: start_thread (pthread_create.c:486) ==24838== Block was alloc'd at ==24838== at 0x4837B65: calloc (vg_replace_malloc.c:752) ==24838== by 0x21FE44: ber_memcalloc_x (memory.c:283) ==24838== by 0x14DB62: ch_calloc (ch_malloc.c:104) ==24838== by 0x13F661: backend_startup_one (backend.c:200) ==24838== by 0x13F98A: backend_startup (backend.c:325) ==24838== by 0x15F920: slap_startup (init.c:219) ==24838== by 0x119D22: main (main.c:1005) ==24838==

1 0

(ITS#9182) slapd crash with invalid pcache config
by ryan＠openldap.org 11 Mar '20

11 Mar '20

Full_Name: Ryan Tandy Version: RE24 OS: Debian URL: Submission from: (NULL) (70.66.128.207) Submitted by: ryan Reported in IRC #openldap by user Dragnell, reproduced by me on current RE24. Configure slapd like so: -- include servers/slapd/schema/core.schema include servers/slapd/schema/cosine.schema include servers/slapd/schema/inetorgperson.schema database config rootpw secret database ldap -- Now try to add the following LDIF: ./clients/tools/ldapmodify -H ldap://:9000 -x -D cn=config -w secret dn: olcOverlay=pcache,olcDatabase={1}ldap,cn=config changetype: add objectClass: olcPcacheConfig olcPcache: mdb 100000 1 1000 100 olcPcacheAttrset: 0 mail olcPcacheTemplate: "(&(objectClass=inetOrgPerson)(mail=))" 0 3600 On the first attempt, the config is rejected: adding new entry "olcOverlay=pcache,olcDatabase={1}ldap,cn=config" ldap_add: Other (e.g., implementation specific) error (80) additional info: unable to parse template: AttributeDescription contains inappropriate characters If you try a second time to add the same LDIF, slapd crashes: adding new entry "olcOverlay=pcache,olcDatabase={1}ldap,cn=config" ldap_result: Can't contact LDAP server (-1) Thread 4 "slapd" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff6cf2700 (LWP 21122)] 0x000055555559cc78 in backend_stopdown_one (bd=0x7fffec102d10) at backend.c:429 429 LDAP_TAILQ_REMOVE( bd->be_pending_csn_list, csne, ce_csn_link ); (gdb) bt #0 0x000055555559cc78 in backend_stopdown_one (bd=0x7fffec102d10) at backend.c:429 #1 0x000055555568ea00 in pcache_db_destroy (be=0x5555558484f0, cr=0x0) at pcache.c:4899 #2 0x000055555561ddad in overlay_destroy_one (be=0x5555558484f0, on=0x7fffec102b30) at backover.c:1150 #3 0x0000555555574b48 in config_add_internal (cfb=0x555555765060 <cfBackInfo>, e=0x555555873598, ca=0x7ffff6cf04f0, rs=0x7ffff6cf1a80, renum=0x7ffff6cf16c0, op=0x7fffec000bb0) at bconfig.c:5318 #4 0x0000555555575131 in config_back_add (op=0x7fffec000bb0, rs=0x7ffff6cf1a80) at bconfig.c:5457 #5 0x00005555555951c7 in fe_op_add (op=0x7fffec000bb0, rs=0x7ffff6cf1a80) at add.c:334 #6 0x0000555555594ac6 in do_add (op=0x7fffec000bb0, rs=0x7ffff6cf1a80) at add.c:194 #7 0x000055555558b879 in connection_operation (ctx=0x7ffff6cf1bb0, arg_v=0x7fffec000bb0) at connection.c:1175 #8 0x000055555558bdf1 in connection_read_thread (ctx=0x7ffff6cf1bb0, argv=0x9) at connection.c:1311 #9 0x00005555556a569d in ldap_int_thread_pool_wrapper (xpool=0x5555557fbec0) at tpool.c:696 #10 0x00007ffff7f86fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486 #11 0x00007ffff7eb74cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 The config in the example is invalid (due to containing a value for objectClass) and it's correct to reject it. However, slapd should not crash.

1 0

(ITS#9181) Non-initialised global options mutex causes problems on Windows
by edwin.mons＠isode.com 10 Mar '20

10 Mar '20

Full_Name: Edwin Mons Version: 2.4 OS: Windows 10 URL: http://edwinm.ik.nu/0001-Initialise-global-options-mutex.patch Submission from: (NULL) (2001:984:e0bf:1:d9ae:17ab:b829:de4f) The global options have a mutex, ldo_mutex, that is left NUL-initialised. This is no problem on must platforms where a mutex is a structure, and all NUL values is a valid mutex, but on Windows, the mutex is a handle. This handle is invalid if it's 0, which causes WaitForSingleObject to return an error. ldap_set_option tries to obtain a lock on the global options. On anything but Windows, this protects data corruption in multi-threaded use, but on Windows, it didn't: there wasn't a mutex to lock, and the result of LDAP_MUTEX_LOCK is never checked. I fixed my local build of OpenLDAP using the attached patch, which satisfied both Application Verifier, and stopped our product from crashing in certain tests that call ldap_set_options from multiple worker threads (in our case, the OpenSSL context was sometimes corrupted.)

1 0

Re: (ITS#9178) Re-connection on lost connection is not propagating LDAP_OPT_REFERRALS option set to off
by laurent.sabourin.74＠gmail.com 10 Mar '20

10 Mar '20

--000000000000f3da4d05a080be37 Content-Type: text/plain; charset="UTF-8" Hello, Please disregard, the issue was in our implementation. You can close this issue. Sorry about that! Laurent On Thu, 5 Mar 2020 at 11:50, <openldap-its(a)openldap.org> wrote: > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#9178. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#9178) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#9178) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=9178 > > Please remember to retain your issue tracking number (ITS#9178) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > > --000000000000f3da4d05a080be37 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Hello,</div><div><br></div>Please disregard, the issu= e was in our implementation. You can close this issue. Sorry about that!<br= ><div><br></div><div>Laurent</div></div><br><div class=3D"gmail_quote"><div= dir=3D"ltr" class=3D"gmail_attr">On Thu, 5 Mar 2020 at 11:50, <<a href= =3D"mailto:openldap-its@openldap.org">openldap-its(a)openldap.org</a>> wro= te:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px = 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br> *** THIS IS AN AUTOMATICALLY GENERATED REPLY ***<br> <br> Thanks for your report to the OpenLDAP Issue Tracking System.=C2=A0 Your<br= > report has been assigned the tracking number ITS#9178.<br> <br> One of our support engineers will look at your report in due course.<br> Note that this may take some time because our support engineers<br> are volunteers.=C2=A0 They only work on OpenLDAP when they have spare<br> time.<br> <br> If you need to provide additional information in regards to your<br> issue report, you may do so by replying to this message.=C2=A0 Note that<br= > any mail sent to <a href=3D"mailto:openldap-its@openldap.org" target=3D"_bl= ank">openldap-its(a)openldap.org</a> with (ITS#9178)<br> in the subject will automatically be attached to the issue report.<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 mailto:<a href=3D"mailto:openldap-its@openldap.= org" target=3D"_blank">openldap-its(a)openldap.org</a>?subject=3D(ITS#9178)<b= r> <br> You may follow the progress of this report by loading the following<br> URL in a web browser:<br> =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/its/index.cgi?findid=3D917= 8" rel=3D"noreferrer" target=3D"_blank">http://www.OpenLDAP.org/its/index.c= gi?findid=3D9178</a><br> <br> Please remember to retain your issue tracking number (ITS#9178)<br> on any further messages you send to us regarding this report.=C2=A0 If<br> you don't then you'll just waste our time and yours because we<br> won't be able to properly track the report.<br> <br> Please note that the Issue Tracking System is not intended to<br> be used to seek help in the proper use of OpenLDAP Software.<br> Such requests will be closed.<br> <br> OpenLDAP Software is user supported.<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/support/" re= l=3D"noreferrer" target=3D"_blank">http://www.OpenLDAP.org/support/</a><br> <br> --------------<br> Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.<br> <br> </blockquote></div> --000000000000f3da4d05a080be37--

1 0

(ITS#9180) Update slapo-memberOf man page about replication
by quanah＠openldap.org 09 Mar '20

09 Mar '20

Full_Name: Quanah Gibson-Mount Version: 2.4.49 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.128.236) After discussion with Howard, slapo-memberOf should be replication compatible on REFRESH as long as the dangling option is set to ignore. The man page should be updated to reflect this, although I want to do some testing to confirm with how it behaves when refint is set to TRUE as well.

1 0

Re: (ITS#9179) back-ldap SASL proxy authorization
by ondra＠mistotebe.net 09 Mar '20

09 Mar '20

On Mon, Mar 09, 2020 at 07:47:17AM +0000, dieterbocklandt(a)gmail.com wrote: > When using SASL proxy authorization in conjunction with the identity assertion > feature of back-ldap, the authentication ID is asserted instead of the expected > authorization ID. A small concrete example (only referencing the relevant > attributes): Hi Dieter, can you post actual configuration, or even better, a script that could be used in ./tests/data/regressions? Just before you do that, I've recently set up the same and if you have your back-ldap to use SASL binds, the code seems to be checking for simple identity is there before it decides to use proxyauthz. Adding a stanza like 'binddn=cn=unused' to the idassert-bind option has worked as a workaround for now. Let me know if that helps in your case. Haven't had a chance to figure out what needs changing, so the regression script would be useful. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

(ITS#9179) back-ldap SASL proxy authorization
by dieterbocklandt＠gmail.com 09 Mar '20

09 Mar '20

Full_Name: Dieter Bocklandt Version: 2.4.49 OS: CentOS 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.85.78.248) When using SASL proxy authorization in conjunction with the identity assertion feature of back-ldap, the authentication ID is asserted instead of the expected authorization ID. A small concrete example (only referencing the relevant attributes): dn: cn=proxy,ou=System,dc=example,dc=net authzTo: dn:* dn: cn=service,ou=System,dc=example,dc=net authzTo: dn:uid=user,ou=People,dc=example,dc=net dn: uid=dieter,ou=People,dc=example,dc=net and the following idassert config: olcDbIDAssertBind: mode=self flags=override,prescriptive bindmethod=sasl saslmech=plain authcID=proxy credentials=XXXXX When I perform an operation like this: ldapmodify -H ldaps://ldapserver -Y PLAIN -U service -X dn:uid=dieter,ou=People,dc=example,dc=net -w servicepassword -f modifications.ldif I would assume the following takes place: - The service user binds to the consumer and assumes dieter's identity, which should be the same net effect as binding with dieter's user in the first place. - The proxy user binds to the provider and assumes dieter's identity - The provider tries to perform the write, using dieter's identity for ACL evaluation What actually happens: - The service user binds to the consumer and assumes dieter's identity - The proxy user binds to the provider and assumes the service user's identity - The provider tries to perform the write, using the service user's identity for ACL evaluation Looking a bit deeper into this, I believe the following piece of code causes this behavior: (from servers/slapd/back-ldap/bind.c in master): line 2222 - 2227: if ( !BER_BVISNULL( &op->o_conn->c_ndn ) ) { ndn = op->o_conn->c_ndn; } else { ndn = op->o_ndn; } line 2549 - 2557: if ( op->o_tag == LDAP_REQ_BIND ) { ndn = op->o_req_ndn; } else if ( !BER_BVISNULL( &op->o_conn->c_ndn ) ) { ndn = op->o_conn->c_ndn; } else { ndn = op->o_ndn; } It seems it tries to use op->o_conn->c_ndn if it's not null, which is (correct me if I'm wrong) the original authcID. That value however doesn't change when performing a proxy authorization, while op->o_ndn does properly reflect that. Shouldn't OpenLDAP always use op->o_ndn? Regards, Dieter

1 0

Re: (ITS#9037) observing crash in mdb_cursor_put()
by hyc＠symas.com 08 Mar '20

08 Mar '20

hyc(a)symas.com wrote: > Robins George wrote: >> Hello Howard, > > Hello again. Revisiting this trace and walkthrough: > >> we are not able to reproduce the issue consistently so test code is not available at this time, and I do believe this issue will be present in the latest code as well since Myk also reported the same.. Attaching analysis from our side, hope it helps. >> >> The call stack what we have seen is, >> >> #0 0x0011b62e in mdb_cursor_put (mc=0xffe52d18, key=0xffe52e74, data=0xffe52e6c, flags=0) at mdb.c:6688 >> #1 0x0011c8ec in mdb_put (txn=0xdc13f008, dbi=2, key=0xffe52e74, data=0xffe52e6c, flags=0) at mdb.c:8771 >> #2 0x00b792b8 in LMDB::LMDBContext::createSession (this=0x80ca418, sid=0x8297be4 "sidebf3708f0fd9fcb8e062529da47adf51402dfc4600000000+") at lmdbint.cc:460 >> #3 0x08053564 in updateLMDB (request=..., forward=@0xffe5315f) at sessionserver.cc:1075 >> #4 processRequestWithoutResponse (request=..., forward=@0xffe5315f) at sessionserver.cc:1160 >> #5 0x08056a80 in processRequest (this=0x80b2ac0, fd=33) at sessionserver.cc:1189 >> #6 readFromSock (this=0x80b2ac0, fd=33) at sessionserver.cc:1342 >> #7 SockHandler::ioReady (this=0x80b2ac0, fd=33) at sessionserver.cc:1455 >> #8 0x00ba2592 in runCoreDispatcher (default_t=<value optimized out>, flags=-1) at fds.cc:889 >> #9 0x00ba2ff7 in DSEvntFds::runDispatcher () at fds.cc:945 >> #10 0x080559c6 in main () at sessionserver.cc:1739 >> >> Here it is helpful to examine frames #0 and #1 in detail in relation to the relevant source code /libraries/liblmdb/mdb.c. >> >> Frame #1 >> >> #1 0x0011c8ec in mdb_put (txn=0xdc13f008, dbi=2, key=0xffe52e74, data=0xffe52e6c, flags=0) at mdb.c:8771 >> mc = {mc_next = 0x0, mc_backup = 0x0, mc_xcursor = 0x0, mc_txn = 0xdc13f008, mc_dbi = 2, mc_db = 0xdc13f088, mc_dbx = 0xe1215038, mc_dbflag = 0xdc1cf09a "\033", '\032' <repeats 51 times>, mc_snum = 0, mc_top = 0, mc_flags = 0, mc_pg = {0x0, 0x80b2ac0, 0xffe52d68, 0x28afce, 0xdc13f008, 0x80ce9b0, 0xffe52dc8, 0x4c5ff4, 0x2b, 0x80b2ac0, 0xffe52d98, 0x49209a, 0x2b, 0x4c5ff4, 0x2121cb, 0x21576c, 0x8297d34, 0x3497af, 0x21576c, 0x21316a, 0x8297d34, 0x80ac7b0, 0x1e, 0x46eed6, 0x2b, 0x0, 0x80ce9b0, 0x4c5ff4, 0x80ac7b0, 0x8297d34, 0xffe52df8, 0x46fb96}, mc_ki = {0, 2089, 51120, 2058, 30, 0, 16796, 17, 11760, 65509, 3, 0, 32040, 2089, 30, 0, 0, 0, 0, 0, 3, 0, 24564, 76, 51120, 2058, 10944, 2059, 11800, 65509, 64758, 70}} <-------- >> >> mx = {mx_cursor = {mc_next = 0x38, mc_backup = 0x3, mc_xcursor = 0x0, mc_txn = 0x0, mc_dbi = 0, mc_db = 0x28, mc_dbx = 0x0, mc_dbflag = 0x0, mc_snum = 3, mc_top = 0, mc_flags = 17, mc_pg = {0x3a93d8, 0x10, 0x0, 0x18, 0x3a93a0, 0x0, 0x3a93d0, 0x289abe, 0x3a93a0, 0xffe52d3f, 0xffe52c68, 0x28afce, 0xffe52dbc, 0xffe52db4, 0x3, 0x4c5ff4, 0x11, 0x36c99b, 0x6e, 0x77, 0x7c, 0x5b, 0x38, 0x289abe, 0x0, 0x0, 0x0, 0x28, 0x0, 0x0, 0x3, 0x10}, mc_ki = {37848, 58, 51611, 54, 110, 0, 119, 0, 124, 0, 91, 0, 58, 0, 39614, 40, 0, 0, 0, 0, 0, 0, 160, 0, 0, 0, 2, 0, 18, 0, 136, 0}}, mx_db = {md_pad = 3838936, md_flags = 51611, md_depth = 54, md_branch_pages = 110, md_leaf_pages = 119, md_overflow_pages = 124, md_entries = 91, md_root = 56}, mx_dbx = {md_name = {mv_size = 6, mv_data = 0x0}, md_cmp = 0, md_dcmp = 0, md_rel = 0x40, md_relctx = 0x0}, mx_dbflag = 0 '\000'} >> rc = 0 >> >> And source code for mdb_put() is from mdb.c >> >> int >> mdb_put(MDB_txn *txn, MDB_dbi dbi, >> MDB_val *key, MDB_val *data, unsigned int flags) >> { >> MDB_cursor mc; >> MDB_xcursor mx; >> int rc; >> >> if (!key || !data || !TXN_DBI_EXIST(txn, dbi, DB_USRVALID)) >> return EINVAL; >> >> if (flags & ~(MDB_NOOVERWRITE|MDB_NODUPDATA|MDB_RESERVE|MDB_APPEND|MDB_APPENDDUP)) >> return EINVAL; >> >> if (txn->mt_flags & (MDB_TXN_RDONLY|MDB_TXN_BLOCKED)) >> return (txn->mt_flags & MDB_TXN_RDONLY) ? EACCES : MDB_BAD_TXN; >> >> mdb_cursor_init(&mc, txn, dbi, &mx); <-------- see source code below >> mc.mc_next = txn->mt_cursors[dbi]; >> txn->mt_cursors[dbi] = &mc; >> rc = mdb_cursor_put(&mc, key, data, flags); <-------- see Frame #0 >> txn->mt_cursors[dbi] = mc.mc_next; >> return rc; >> } >> >> >> Source Code For mdb_cursor_init() From mdb.c >> /** Initialize a cursor for a given transaction and database. */ >> static void >> mdb_cursor_init(MDB_cursor *mc, MDB_txn *txn, MDB_dbi dbi, MDB_xcursor *mx) >> { >> mc->mc_next = NULL; >> mc->mc_backup = NULL; >> mc->mc_dbi = dbi; >> mc->mc_txn = txn; >> mc->mc_db = &txn->mt_dbs[dbi]; >> mc->mc_dbx = &txn->mt_dbxs[dbi]; >> mc->mc_dbflag = &txn->mt_dbflags[dbi]; >> mc->mc_snum = 0; <-------- >> mc->mc_top = 0; <-------- >> mc->mc_pg[0] = 0; <-------- >> mc->mc_ki[0] = 0; >> mc->mc_flags = 0; >> if (txn->mt_dbs[dbi].md_flags & MDB_DUPSORT) { >> mdb_tassert(txn, mx != NULL); >> mc->mc_xcursor = mx; >> mdb_xcursor_init0(mc); >> } else { >> mc->mc_xcursor = NULL; >> } >> if (*mc->mc_dbflag & DB_STALE) { <-------- false *mc->mc_dbflag = 27, DB_STALE = 0x02 /**< Named-DB record is older than txnID */ > > 27 = 0x1B, this DB is stale and this test is true, not false. > >> mdb_page_search(mc, NULL, MDB_PS_ROOTONLY); >> } >> } >> >> From this we know that when mdb_cursor_put() is called, the following values remain assigned: >> >> mc->mc_snum = 0; <-------- >> mc->mc_top = 0; <-------- >> mc->mc_pg[0] = 0; <-------- >> >> and its noted these two values still have their initial values at the time of the segmentation fault. >> >> (gdb) fr 0 >> #0 0x0011b62e in mdb_cursor_put (mc=0xffe52d18, key=0xffe52e74, data=0xffe52e6c, flags=0) at mdb.c:6688 >> 6688 in mdb.c >> (gdb) p mc->mc_top >> $1 = 0 >> (gdb) p mc->mc_pg[mc->mc_top] >> $19 = (MDB_page *) 0x0 >> >> Let us consider how the path taken through mdb_cursor_put() could account for these null variable values which result in a segmentation fault. >> >> Frame #0 >> >> #0 0x0011b62e in mdb_cursor_put (mc=0xffe52d18, key=0xffe52e74, data=0xffe52e6c, flags=0) at mdb.c:6688 <-------- flags = 0 >> env = 0x80ce9b0 >> leaf = <value optimized out> >> fp = <value optimized out> >> mp = 0x38 >> sub_root = 0x0 >> fp_flags = <value optimized out> >> xdata = {mv_size = 3838880, mv_data = 0xdc1cf09a} >> rdata = 0xffe52e6c >> dkey = {mv_size = 0, mv_data = 0x3a93cc} >> olddata = {mv_size = 22, mv_data = 0x36c820} >> dummy = {md_pad = 22, md_flags = 11128, md_depth = 65509, md_branch_pages = 16, md_leaf_pages = 1507329, md_overflow_pages = 0, md_entries = 3838928, md_root = 3833844} >> do_sub = 0 >> insert_key = -30798 <-------- #define MDB_NOTFOUND (-30798) >> insert_data = -30798 <-------- #define MDB_NOTFOUND (-30798) >> mcount = 0 >> dcount = 0 >> nospill = 0 <-------- >> nsize = <value optimized out> >> rc = 0 >> rc2 = <value optimized out> >> nflags = 0 <-------- >> __func__ = "mdb_cursor_put" >> >> We know that mc->mc_top and mc->mc_pg[0] were initialized to 0 in mdb_cursor_init(). As my annotations of the source code below suggest, careful analysis reveals that the paths actually taken through mdb_cursor_put() do not modify these assignments. >> >> Excerpted Source Code For mdb_cursor_put() From mdb.c >> >> int >> mdb_cursor_put(MDB_cursor *mc, MDB_val *key, MDB_val *data, >> unsigned int flags) >> { >> MDB_env *env; >> MDB_node *leaf = NULL; >> MDB_page *fp, *mp, *sub_root = NULL; >> uint16_t fp_flags; >> MDB_val xdata, *rdata, dkey, olddata; >> MDB_db dummy; >> int do_sub = 0, insert_key, insert_data; >> unsigned int mcount = 0, dcount = 0, nospill; >> size_t nsize; >> int rc, rc2; >> unsigned int nflags; >> DKBUF; >> >> if (mc == NULL || key == NULL) >> return EINVAL; >> >> env = mc->mc_txn->mt_env; >> >> /* Check this first so counter will always be zero on any >> * early failures. >> */ >> if (flags & MDB_MULTIPLE) { >> dcount = data[1].mv_size; >> data[1].mv_size = 0; >> if (!F_ISSET(mc->mc_db->md_flags, MDB_DUPFIXED)) >> return MDB_INCOMPATIBLE; >> } >> >> nospill = flags & MDB_NOSPILL; >> flags &= ~MDB_NOSPILL; >> >> if (mc->mc_txn->mt_flags & (MDB_TXN_RDONLY|MDB_TXN_BLOCKED)) >> return (mc->mc_txn->mt_flags & MDB_TXN_RDONLY) ? EACCES : MDB_BAD_TXN; >> >> if (key->mv_size-1 >= ENV_MAXKEY(env)) >> return MDB_BAD_VALSIZE; >> >> #if SIZE_MAX > MAXDATASIZE >> if (data->mv_size > ((mc->mc_db->md_flags & MDB_DUPSORT) ? ENV_MAXKEY(env) : MAXDATASIZE)) >> return MDB_BAD_VALSIZE; >> #else >> if ((mc->mc_db->md_flags & MDB_DUPSORT) && data->mv_size > ENV_MAXKEY(env)) >> return MDB_BAD_VALSIZE; >> #endif >> >> DPRINTF(("==> put db %d key [%s], size %"Z"u, data size %"Z"u", >> DDBI(mc), DKEY(key), key ? key->mv_size : 0, data->mv_size)); >> >> dkey.mv_size = 0; >> >> if (flags == MDB_CURRENT) { <-------- false flags = 0 >> if (!(mc->mc_flags & C_INITIALIZED)) >> return EINVAL; >> rc = MDB_SUCCESS; >> } else if (mc->mc_db->md_root == P_INVALID) { <-------- false, mc->mc_db->md_root = 68 > > I might have missed it, did you show the entire contents of *mc->mc_db somewhere? > >> /* new database, cursor has nothing to point to */ >> mc->mc_snum = 0; >> mc->mc_top = 0; >> mc->mc_flags &= ~C_INITIALIZED; >> rc = MDB_NO_ROOT; >> } else { <-------- executed >> int exact = 0; >> MDB_val d2; >> if (flags & MDB_APPEND) { <-------- false flags = 0 >> MDB_val k2; >> rc = mdb_cursor_last(mc, &k2, &d2); >> if (rc == 0) { >> rc = mc->mc_dbx->md_cmp(key, &k2); >> if (rc > 0) { >> rc = MDB_NOTFOUND; >> mc->mc_ki[mc->mc_top]++; >> } else { >> /* new key is <= last key */ >> rc = MDB_KEYEXIST; >> } >> } >> } else {<-------- executed >> rc = mdb_cursor_set(mc, key, &d2, MDB_SET, &exact); <-------- returns -30798 which is MDB_NOTFOUND > > This is an important step. mdb_cursor_set only returns MDB_NOTFOUND when mc->mc_pg[mc->mc_top] != NULL. > There are no code paths that can return this error code without setting the rootpage pointer mc->mc_pg[0] non-NULL. > The only path that can allow this is if mc->mc_db->md_root == P_INVALID (the tree is empty) and we already know > that's not true in this case. Nothing in LMDB will change these values between the time mdb_cursor_set > returned and the time that mdb_cursor_put tries to reference mc->mc_pg[]. As such this sounds like a > memory overwrite corruption from some other thread, unrelated to LMDB. > You can verify this by adding an assert after the mdb_cursor_set() call: mdb_cassert(mc, rc != MDB_NOTFOUND || mc->mc_pg != NULL); At this point I would check to see if your threads' stack sizes are large enough. Since this cursor came from mdb_put, it lives on the stack, and a stack overrun is the most likely culprit. -- -- 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#9037) observing crash in mdb_cursor_put()
by hyc＠symas.com 08 Mar '20

08 Mar '20

Robins George wrote: > Hello Howard, Hello again. Revisiting this trace and walkthrough: > we are not able to reproduce the issue consistently so test code is not available at this time, and I do believe this issue will be present in the latest code as well since Myk also reported the same.. Attaching analysis from our side, hope it helps. > > The call stack what we have seen is, > > #0 0x0011b62e in mdb_cursor_put (mc=0xffe52d18, key=0xffe52e74, data=0xffe52e6c, flags=0) at mdb.c:6688 > #1 0x0011c8ec in mdb_put (txn=0xdc13f008, dbi=2, key=0xffe52e74, data=0xffe52e6c, flags=0) at mdb.c:8771 > #2 0x00b792b8 in LMDB::LMDBContext::createSession (this=0x80ca418, sid=0x8297be4 "sidebf3708f0fd9fcb8e062529da47adf51402dfc4600000000+") at lmdbint.cc:460 > #3 0x08053564 in updateLMDB (request=..., forward=@0xffe5315f) at sessionserver.cc:1075 > #4 processRequestWithoutResponse (request=..., forward=@0xffe5315f) at sessionserver.cc:1160 > #5 0x08056a80 in processRequest (this=0x80b2ac0, fd=33) at sessionserver.cc:1189 > #6 readFromSock (this=0x80b2ac0, fd=33) at sessionserver.cc:1342 > #7 SockHandler::ioReady (this=0x80b2ac0, fd=33) at sessionserver.cc:1455 > #8 0x00ba2592 in runCoreDispatcher (default_t=<value optimized out>, flags=-1) at fds.cc:889 > #9 0x00ba2ff7 in DSEvntFds::runDispatcher () at fds.cc:945 > #10 0x080559c6 in main () at sessionserver.cc:1739 > > Here it is helpful to examine frames #0 and #1 in detail in relation to the relevant source code /libraries/liblmdb/mdb.c. > > Frame #1 > > #1 0x0011c8ec in mdb_put (txn=0xdc13f008, dbi=2, key=0xffe52e74, data=0xffe52e6c, flags=0) at mdb.c:8771 > mc = {mc_next = 0x0, mc_backup = 0x0, mc_xcursor = 0x0, mc_txn = 0xdc13f008, mc_dbi = 2, mc_db = 0xdc13f088, mc_dbx = 0xe1215038, mc_dbflag = 0xdc1cf09a "\033", '\032' <repeats 51 times>, mc_snum = 0, mc_top = 0, mc_flags = 0, mc_pg = {0x0, 0x80b2ac0, 0xffe52d68, 0x28afce, 0xdc13f008, 0x80ce9b0, 0xffe52dc8, 0x4c5ff4, 0x2b, 0x80b2ac0, 0xffe52d98, 0x49209a, 0x2b, 0x4c5ff4, 0x2121cb, 0x21576c, 0x8297d34, 0x3497af, 0x21576c, 0x21316a, 0x8297d34, 0x80ac7b0, 0x1e, 0x46eed6, 0x2b, 0x0, 0x80ce9b0, 0x4c5ff4, 0x80ac7b0, 0x8297d34, 0xffe52df8, 0x46fb96}, mc_ki = {0, 2089, 51120, 2058, 30, 0, 16796, 17, 11760, 65509, 3, 0, 32040, 2089, 30, 0, 0, 0, 0, 0, 3, 0, 24564, 76, 51120, 2058, 10944, 2059, 11800, 65509, 64758, 70}} <-------- > > mx = {mx_cursor = {mc_next = 0x38, mc_backup = 0x3, mc_xcursor = 0x0, mc_txn = 0x0, mc_dbi = 0, mc_db = 0x28, mc_dbx = 0x0, mc_dbflag = 0x0, mc_snum = 3, mc_top = 0, mc_flags = 17, mc_pg = {0x3a93d8, 0x10, 0x0, 0x18, 0x3a93a0, 0x0, 0x3a93d0, 0x289abe, 0x3a93a0, 0xffe52d3f, 0xffe52c68, 0x28afce, 0xffe52dbc, 0xffe52db4, 0x3, 0x4c5ff4, 0x11, 0x36c99b, 0x6e, 0x77, 0x7c, 0x5b, 0x38, 0x289abe, 0x0, 0x0, 0x0, 0x28, 0x0, 0x0, 0x3, 0x10}, mc_ki = {37848, 58, 51611, 54, 110, 0, 119, 0, 124, 0, 91, 0, 58, 0, 39614, 40, 0, 0, 0, 0, 0, 0, 160, 0, 0, 0, 2, 0, 18, 0, 136, 0}}, mx_db = {md_pad = 3838936, md_flags = 51611, md_depth = 54, md_branch_pages = 110, md_leaf_pages = 119, md_overflow_pages = 124, md_entries = 91, md_root = 56}, mx_dbx = {md_name = {mv_size = 6, mv_data = 0x0}, md_cmp = 0, md_dcmp = 0, md_rel = 0x40, md_relctx = 0x0}, mx_dbflag = 0 '\000'} > rc = 0 > > And source code for mdb_put() is from mdb.c > > int > mdb_put(MDB_txn *txn, MDB_dbi dbi, > MDB_val *key, MDB_val *data, unsigned int flags) > { > MDB_cursor mc; > MDB_xcursor mx; > int rc; > > if (!key || !data || !TXN_DBI_EXIST(txn, dbi, DB_USRVALID)) > return EINVAL; > > if (flags & ~(MDB_NOOVERWRITE|MDB_NODUPDATA|MDB_RESERVE|MDB_APPEND|MDB_APPENDDUP)) > return EINVAL; > > if (txn->mt_flags & (MDB_TXN_RDONLY|MDB_TXN_BLOCKED)) > return (txn->mt_flags & MDB_TXN_RDONLY) ? EACCES : MDB_BAD_TXN; > > mdb_cursor_init(&mc, txn, dbi, &mx); <-------- see source code below > mc.mc_next = txn->mt_cursors[dbi]; > txn->mt_cursors[dbi] = &mc; > rc = mdb_cursor_put(&mc, key, data, flags); <-------- see Frame #0 > txn->mt_cursors[dbi] = mc.mc_next; > return rc; > } > > > Source Code For mdb_cursor_init() From mdb.c > /** Initialize a cursor for a given transaction and database. */ > static void > mdb_cursor_init(MDB_cursor *mc, MDB_txn *txn, MDB_dbi dbi, MDB_xcursor *mx) > { > mc->mc_next = NULL; > mc->mc_backup = NULL; > mc->mc_dbi = dbi; > mc->mc_txn = txn; > mc->mc_db = &txn->mt_dbs[dbi]; > mc->mc_dbx = &txn->mt_dbxs[dbi]; > mc->mc_dbflag = &txn->mt_dbflags[dbi]; > mc->mc_snum = 0; <-------- > mc->mc_top = 0; <-------- > mc->mc_pg[0] = 0; <-------- > mc->mc_ki[0] = 0; > mc->mc_flags = 0; > if (txn->mt_dbs[dbi].md_flags & MDB_DUPSORT) { > mdb_tassert(txn, mx != NULL); > mc->mc_xcursor = mx; > mdb_xcursor_init0(mc); > } else { > mc->mc_xcursor = NULL; > } > if (*mc->mc_dbflag & DB_STALE) { <-------- false *mc->mc_dbflag = 27, DB_STALE = 0x02 /**< Named-DB record is older than txnID */ 27 = 0x1B, this DB is stale and this test is true, not false. > mdb_page_search(mc, NULL, MDB_PS_ROOTONLY); > } > } > > From this we know that when mdb_cursor_put() is called, the following values remain assigned: > > mc->mc_snum = 0; <-------- > mc->mc_top = 0; <-------- > mc->mc_pg[0] = 0; <-------- > > and its noted these two values still have their initial values at the time of the segmentation fault. > > (gdb) fr 0 > #0 0x0011b62e in mdb_cursor_put (mc=0xffe52d18, key=0xffe52e74, data=0xffe52e6c, flags=0) at mdb.c:6688 > 6688 in mdb.c > (gdb) p mc->mc_top > $1 = 0 > (gdb) p mc->mc_pg[mc->mc_top] > $19 = (MDB_page *) 0x0 > > Let us consider how the path taken through mdb_cursor_put() could account for these null variable values which result in a segmentation fault. > > Frame #0 > > #0 0x0011b62e in mdb_cursor_put (mc=0xffe52d18, key=0xffe52e74, data=0xffe52e6c, flags=0) at mdb.c:6688 <-------- flags = 0 > env = 0x80ce9b0 > leaf = <value optimized out> > fp = <value optimized out> > mp = 0x38 > sub_root = 0x0 > fp_flags = <value optimized out> > xdata = {mv_size = 3838880, mv_data = 0xdc1cf09a} > rdata = 0xffe52e6c > dkey = {mv_size = 0, mv_data = 0x3a93cc} > olddata = {mv_size = 22, mv_data = 0x36c820} > dummy = {md_pad = 22, md_flags = 11128, md_depth = 65509, md_branch_pages = 16, md_leaf_pages = 1507329, md_overflow_pages = 0, md_entries = 3838928, md_root = 3833844} > do_sub = 0 > insert_key = -30798 <-------- #define MDB_NOTFOUND (-30798) > insert_data = -30798 <-------- #define MDB_NOTFOUND (-30798) > mcount = 0 > dcount = 0 > nospill = 0 <-------- > nsize = <value optimized out> > rc = 0 > rc2 = <value optimized out> > nflags = 0 <-------- > __func__ = "mdb_cursor_put" > > We know that mc->mc_top and mc->mc_pg[0] were initialized to 0 in mdb_cursor_init(). As my annotations of the source code below suggest, careful analysis reveals that the paths actually taken through mdb_cursor_put() do not modify these assignments. > > Excerpted Source Code For mdb_cursor_put() From mdb.c > > int > mdb_cursor_put(MDB_cursor *mc, MDB_val *key, MDB_val *data, > unsigned int flags) > { > MDB_env *env; > MDB_node *leaf = NULL; > MDB_page *fp, *mp, *sub_root = NULL; > uint16_t fp_flags; > MDB_val xdata, *rdata, dkey, olddata; > MDB_db dummy; > int do_sub = 0, insert_key, insert_data; > unsigned int mcount = 0, dcount = 0, nospill; > size_t nsize; > int rc, rc2; > unsigned int nflags; > DKBUF; > > if (mc == NULL || key == NULL) > return EINVAL; > > env = mc->mc_txn->mt_env; > > /* Check this first so counter will always be zero on any > * early failures. > */ > if (flags & MDB_MULTIPLE) { > dcount = data[1].mv_size; > data[1].mv_size = 0; > if (!F_ISSET(mc->mc_db->md_flags, MDB_DUPFIXED)) > return MDB_INCOMPATIBLE; > } > > nospill = flags & MDB_NOSPILL; > flags &= ~MDB_NOSPILL; > > if (mc->mc_txn->mt_flags & (MDB_TXN_RDONLY|MDB_TXN_BLOCKED)) > return (mc->mc_txn->mt_flags & MDB_TXN_RDONLY) ? EACCES : MDB_BAD_TXN; > > if (key->mv_size-1 >= ENV_MAXKEY(env)) > return MDB_BAD_VALSIZE; > > #if SIZE_MAX > MAXDATASIZE > if (data->mv_size > ((mc->mc_db->md_flags & MDB_DUPSORT) ? ENV_MAXKEY(env) : MAXDATASIZE)) > return MDB_BAD_VALSIZE; > #else > if ((mc->mc_db->md_flags & MDB_DUPSORT) && data->mv_size > ENV_MAXKEY(env)) > return MDB_BAD_VALSIZE; > #endif > > DPRINTF(("==> put db %d key [%s], size %"Z"u, data size %"Z"u", > DDBI(mc), DKEY(key), key ? key->mv_size : 0, data->mv_size)); > > dkey.mv_size = 0; > > if (flags == MDB_CURRENT) { <-------- false flags = 0 > if (!(mc->mc_flags & C_INITIALIZED)) > return EINVAL; > rc = MDB_SUCCESS; > } else if (mc->mc_db->md_root == P_INVALID) { <-------- false, mc->mc_db->md_root = 68 I might have missed it, did you show the entire contents of *mc->mc_db somewhere? > /* new database, cursor has nothing to point to */ > mc->mc_snum = 0; > mc->mc_top = 0; > mc->mc_flags &= ~C_INITIALIZED; > rc = MDB_NO_ROOT; > } else { <-------- executed > int exact = 0; > MDB_val d2; > if (flags & MDB_APPEND) { <-------- false flags = 0 > MDB_val k2; > rc = mdb_cursor_last(mc, &k2, &d2); > if (rc == 0) { > rc = mc->mc_dbx->md_cmp(key, &k2); > if (rc > 0) { > rc = MDB_NOTFOUND; > mc->mc_ki[mc->mc_top]++; > } else { > /* new key is <= last key */ > rc = MDB_KEYEXIST; > } > } > } else {<-------- executed > rc = mdb_cursor_set(mc, key, &d2, MDB_SET, &exact); <-------- returns -30798 which is MDB_NOTFOUND This is an important step. mdb_cursor_set only returns MDB_NOTFOUND when mc->mc_pg[mc->mc_top] != NULL. There are no code paths that can return this error code without setting the rootpage pointer mc->mc_pg[0] non-NULL. The only path that can allow this is if mc->mc_db->md_root == P_INVALID (the tree is empty) and we already know that's not true in this case. Nothing in LMDB will change these values between the time mdb_cursor_set returned and the time that mdb_cursor_put tries to reference mc->mc_pg[]. As such this sounds like a memory overwrite corruption from some other thread, unrelated to LMDB. -- -- 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#8639) Remove support for LANMAN
by ryan＠nardis.ca 07 Mar '20

07 Mar '20

Tested smbk5pwd with Samba 4.9.5 (both openssl and gnutls). Works for me, so pushed to master now. Further testing would be appreciated.

1 0

(ITS#9178) Re-connection on lost connection is not propagating LDAP_OPT_REFERRALS option set to off
by laurent.sabourin.74＠gmail.com 05 Mar '20

05 Mar '20

Full_Name: Laurent Sabourin Version: openldap-2.4.48 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.218.42.174) I am using OpenLDAP libraries within my software for my LDAP client implementation. For the LDAP session handles where I set the option LDAP_OPT_REFERRALS to LDAP_OPT_OFF, it seems that that option is not being propagated when OpenLDAP reconnects after the server dropped the initial connection. Because of that, all subsequent searches start following referrals even though the option was turned off initially. How to reproduce: 1- Make a LDAP search to LDAP server that returns referrals (Windows AD in my case) with referrals turned off. The search doesn't follow referrals. 2- Drop the connection with the LDAP server (I used SysInternals TCPView to force the connection to close) 3- Make the same LDAP search using the same LDAP session handle used in step 1. OpenLDAP reconnects, but the search unexpectedly follows the referrals. Expected behavior: I would expect the LDAP session handle to retain original options even when it reconnects drop connections.

1 0

Re: (ITS#8639) Remove support for LANMAN
by ryan＠nardis.ca 05 Mar '20

05 Mar '20

I put up my WIP branch on github: https://github.com/openldap/openldap/compare/master...rtandy:its8639 Still need to finish testing smbk5pwd before I can push it.

1 0

(ITS#9177) Finish the autoconf 2.69 upgrade
by ryan＠openldap.org 28 Feb '20

28 Feb '20

Full_Name: Ryan Tandy Version: master OS: URL: Submission from: (NULL) (70.66.128.207) Submitted by: ryan autoconf 2.69 upgrade was only partially completed. So far we have autoconf (6b81910fc) and autoheader (c2f75cd10). However running autoreconf 2.69 still generates more diffs. At least aclocal still needs to be run. This ITS is a reminder to check what else autoreconf does and check in the remaining changes. In future it might be good practice to get in the habit of running autoreconf instead of just autoconf. It tries and fails to run Automake, but that can probably be addressed (possibly by deleting the AM_INIT_AUTOMAKE call).

1 0

Re: (ITS#8639) Remove support for LANMAN
by michael＠stroeder.com 28 Feb '20

28 Feb '20

On 2/28/20 8:40 PM, ryan(a)nardis.ca wrote: > Are you aware of any scenarios where > sambaLMPassword is actually required today? Personally I'm more inclined > to just delete the code rather than #ifdef it; people can always grab > the older code if they really need that. +1 for hunking out LANMAN hashes completely. Ciao, Michael.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs