openldap-bugs March 2020

openldap-bugs@openldap.org

9 participants
1404 discussions

Start a nNew thread

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 10 Mar '20

10 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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2020