openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

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

04 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

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

28 Feb '20

Hello, On Thu, Feb 20, 2020 at 03:50:38PM +0000, fumiyas(a)osstech.co.jp wrote: >I've created a path for smbk5pwd to disable the insecure sambaLMPassword >support by default. Thanks for this patch. 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 0

Re: (ITS#9171) slapd with ppolicy and pwdAccountLockedTime crashes
by tokos＠ipp.cas.cz 21 Feb '20

21 Feb '20

--000000000000b0a76e059f255a73 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ondrej, I really appreciate so quick fix. Regards Stanislav p=C3=A1 21. 2. 2020 v 11:49 odes=C3=ADlatel Ond=C5=99ej Kuzn=C3=ADk <ondra@= mistotebe.net> napsal: > On Mon, Feb 17, 2020 at 02:17:32PM +0000, tokos(a)ipp.cas.cz wrote: > > Hi Ondrej, > > > > I uploaded my configuration here(ftp.openldap.org/incoming) : > > Hi Stanislav, > thanks for the information, I have been able to reproduce the issue and > pushed a fix to master (commit 140b676bc1bd786f9fd1e7b047981e84b57cb354). > > Regards, > > -- > Ond=C5=99ej Kuzn=C3=ADk > Senior Software Engineer > Symas Corporation http://www.symas.com > Packaged, certified, and supported LDAP solutions powered by OpenLDAP > --000000000000b0a76e059f255a73 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Hi Ondrej,</div><div><br></div><div>=C2=A0 I really a= ppreciate so quick fix. <br></div><div><br></div><div>Regards</div><div><br= ></div><div>Stanislav<br></div></div><br><div class=3D"gmail_quote"><div di= r=3D"ltr" class=3D"gmail_attr">p=C3=A1 21. 2. 2020 v=C2=A011:49 odes=C3=ADl= atel Ond=C5=99ej Kuzn=C3=ADk <<a href=3D"mailto:ondra@mistotebe.net">ond= ra(a)mistotebe.net</a>> napsal:<br></div><blockquote class=3D"gmail_quote"= style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p= adding-left:1ex">On Mon, Feb 17, 2020 at 02:17:32PM +0000, <a href=3D"mailt= o:tokos@ipp.cas.cz" target=3D"_blank">tokos(a)ipp.cas.cz</a> wrote:<br> > Hi Ondrej,<br> > <br> >=C2=A0 =C2=A0I uploaded my configuration here(<a href=3D"http://ftp.ope= nldap.org/incoming" rel=3D"noreferrer" target=3D"_blank">ftp.openldap.org/i= ncoming</a>) :<br> <br> Hi Stanislav,<br> thanks for the information, I have been able to reproduce the issue and<br> pushed a fix to master (commit 140b676bc1bd786f9fd1e7b047981e84b57cb354).<b= r> <br> Regards,<br> <br> -- <br> Ond=C5=99ej Kuzn=C3=ADk<br> Senior Software Engineer<br> Symas Corporation=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"http://www.symas.com" rel=3D"noreferr= er" target=3D"_blank">http://www.symas.com</a><br> Packaged, certified, and supported LDAP solutions powered by OpenLDAP<br> </blockquote></div> --000000000000b0a76e059f255a73--

1 0

Re: (ITS#9175) ldapsearch segfault
by quanah＠symas.com 21 Feb '20

21 Feb '20

Thanks for the report, suggested fix has been applied. Regards, Quanah --On Friday, February 21, 2020 8:38 PM +0000 lhaley(a)meditech.com wrote: > --0000000000003b4d37059f1c0189 > Content-Type: text/plain; charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > footnote: In my first followup, I intended to write "as I am quite > UNaccustomed to working with the data" > Cheers > > On Fri, Feb 21, 2020 at 3:27 PM Lexi Haley <lhaley(a)meditech.com> wrote: > >> FOUND THE ISSUE! So - in GDB , while paused in the "{mM}" processing >> tha= > t >> ber_scanf does (called from ldap_get_attribute_ber), I kept seeing the >> variable arguments list not properly setting off --- and sure enough, >> digging in memory, on the stack was 0x100000000 ... which was the cause >> = > of >> the eventual segfault. >> >> Well, backtracking to the ber_scanf call itself, I see a zero 0 which >> isn't cast to the ber_len_t type, and as such, will only occupy 4 bytes >> a= > s >> a sizeof int - instead of (( on my system 8, for sizeof (ber_len_t). So >> = > - >> the solution was just to cast the argument. So that the cookie.off =3D >> va_arg( ap, ber_len_t ); will unpack only bytes we've intentionally sent >> = > it >> -- not garbage left over. >> >> So - the change suggested is: >> >> >> diff --git a/libraries/libldap/getattr.c b/libraries/libldap/getattr.c >> index 31784d765..0300ea574 100644 >> --- a/libraries/libldap/getattr.c >> +++ b/libraries/libldap/getattr.c >> @@ -147,7 +147,7 @@ ldap_get_attribute_ber( LDAP *ld, LDAPMessage *entry, >> BerElement *ber, >> >> /* skip sequence, snarf attribute type */ >> tag =3D ber_scanf( ber, vals ? "{mM}" : "{mx}", attr, >> val= > s, >> - &siz, 0 ); >> + &siz, (ber_len_t)0 ); >> if( tag =3D=3D LBER_ERROR ) { >> rc =3D ld->ld_errno =3D LDAP_DECODING_ERROR; >> } >> >> >> I hope you can take this haphazard issue submit, and do whatever is right >> with it - to get this patch considered. Thanks! >> >> >> >> On Fri, Feb 21, 2020 at 1:06 PM Lexi Haley <lhaley(a)meditech.com> wrote: >> >>> continuing notes - as I am quite accustomed to working with the data >>> structures and processes for LDAP - my hacky fudge was just that - and >>> a= > lso >>> useless. By bailing out at that point, ldapsearch doesn't list the >>> tag=3Dvalue results. I am continuing to dig around ... >>> >>> Lexi >>> >>> On Thu, Feb 20, 2020 at 3:09 PM <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#9175. >>>> >>>> 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#9175) >>>> in the subject will automatically be attached to the issue report. >>>> >>>> mailto:openldap-its@openldap.org?subject=3D(ITS#9175) >>>> >>>> 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=3D9175 >>>> >>>> Please remember to retain your issue tracking number (ITS#9175) >>>> 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. >>>> >>>> >>> >>> -- >>> >>> Lexi Haley (she/her/hers) >>> >>> Computer Scientist, System Tools, Advanced Technology Division >>> >>> Medical Information Technology, Inc. >>> >>> Office: 781-774-5156 | Mobile: 508-713-2499 >>> >>> lhaley(a)meditech.com >>> >>> MEDITECH Circle, Westwood, MA 02090 >>> >>> Main: 781-821-3000 | Fax: 781-821-2199 >>> >> >> >> -- >> >> Lexi Haley (she/her/hers) >> >> Computer Scientist, System Tools, Advanced Technology Division >> >> Medical Information Technology, Inc. >> >> Office: 781-774-5156 | Mobile: 508-713-2499 >> >> lhaley(a)meditech.com >> >> MEDITECH Circle, Westwood, MA 02090 >> >> Main: 781-821-3000 | Fax: 781-821-2199 >> > > > --=20 > > Lexi Haley (she/her/hers) > > Computer Scientist, System Tools, Advanced Technology Division > > Medical Information Technology, Inc. > > Office: 781-774-5156 | Mobile: 508-713-2499 > > lhaley(a)meditech.com > > MEDITECH Circle, Westwood, MA 02090 > > Main: 781-821-3000 | Fax: 781-821-2199 > > --=20 > <https://ehr.meditech.com/expanse>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= > =A0 =20 > <https://www.linkedin.com/company/meditech>=C2=A0 =20 > <https://twitter.com/MEDITECH>=C2=A0=C2=A0 > <https://www.facebook.com/Medite= chEHR> > > Subscribe=20 > <https://info.meditech.com/get-great-meditech-content?hsCtaTracking=3D864 > 29= > 9ec-5abf-4004-9c6d-2d051794101f%7Cc911be42-538a-4a48-8dca-a6d4001c6326>=20 > to receive emails from MEDITECH or to change email preferences. > > > --0000000000003b4d37059f1c0189 > Content-Type: text/html; charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > <div dir=3D"ltr">footnote:=C2=A0 In my first followup, I intended to > write= =C2=A0 "<span style=3D"color:rgb(0,0,0)">as I am quite > UNaccustomed to= working with the > data"</span><div>Cheers</div></div><br><div class=3D= > "gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Feb 21, 2020 > at= 3:27 PM Lexi Haley <<a > href=3D"mailto:lhaley@meditech.com">lhaley@medit= ech.com</a>> > wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"= margin:0px > 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef= > t:1ex"><div dir=3D"ltr">FOUND THE ISSUE!=C2=A0 So - in GDB , while paused > i= n the "{mM}" processing that ber_scanf does (called > from=C2=A0lda= p_get_attribute_ber), I kept seeing the variable arguments > list not properl= y setting off --- and sure enough, digging in memory, > on the stack was 0x10= 0000000 ...=C2=A0 which was the cause of the > eventual segfault.<div><br></d= iv><div>Well, backtracking to the > ber_scanf call itself, I see a zero 0 whi= ch isn't cast to the > ber_len_t type, and as such, will only occupy 4 by= tes as a > sizeof=C2=A0int - instead of (( on my system 8, for sizeof (ber_le= > n_t).=C2=A0 So - the solution was just=C2=A0to cast the argument.=C2=A0 > So = that the=C2=A0cookie.off =3D va_arg( ap, ber_len_t ); will unpack > only byte= s we've intentionally sent it -- not garbage left > over.</div><div><br><= /div><div>So - the change suggested > is:</div><div><br></div><div><br></div>= <div><font > face=3D"monospace">diff --git a/libraries/libldap/getattr.c b/li= > braries/libldap/getattr.c<br>index 31784d765..0300ea574 100644<br>--- > a/lib= raries/libldap/getattr.c<br>+++ > b/libraries/libldap/getattr.c<br>@@ -147,7 = +147,7 @@ > ldap_get_attribute_ber( LDAP *ld, LDAPMessage *entry, BerElement = > *ber,<br><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* > ski= p sequence, snarf attribute type */<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 = =C2=A0 =C2=A0 =C2=A0 tag =3D ber_scanf( ber, vals ? > "{mM}" : &quo= t;{mx}", attr, vals,<br>- =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > &siz, 0 );<br>+ =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 &siz, (ber_len= _t)0 );<br>=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if( tag = =3D=3D LBER_ERROR ) > {<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 rc =3D ld->ld_errno =3D LDAP_DECODING= > _ERROR;<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > }</font>= <br></div><div><br></div><div><br></div><div>I hope you can > take this hapha= zard issue submit, and do whatever is right with it - to > get this patch con= sidered.=C2=A0 > Thanks!</div><div><br></div><div><br></div></div><br><div cl= > ass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Feb 21, > 2= 020 at 1:06 PM Lexi Haley <<a href=3D"mailto:lhaley@meditech.com" > target= =3D"_blank">lhaley(a)meditech.com</a>> > wrote:<br></div><blockquote class= =3D"gmail_quote" style=3D"margin:0px > 0px 0px 0.8ex;border-left:1px solid rg= > b(204,204,204);padding-left:1ex"><div dir=3D"ltr">continuing notes - as I > a= m quite accustomed to working with the data structures and processes > for LD= AP - my hacky fudge was just that - and also useless.=C2=A0 By > bailing out = at that point, ldapsearch doesn't list the tag=3Dvalue > results.=C2=A0 I= am continuing to dig around > ...<div><br></div><div>Lexi</div></div><br><di= v > class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Feb 2= > 0, 2020 at 3:09 PM <<a href=3D"mailto:openldap-its@openldap.org" > target= =3D"_blank">openldap-its(a)openldap.org</a>> > wrote:<br></div><blockquote c= lass=3D"gmail_quote" style=3D"margin:0px > 0px 0px 0.8ex;border-left:1px soli= d > 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#9175.<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#9175)<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#9175)<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= 5" > rel=3D"noreferrer" target=3D"_blank">http://www.OpenLDAP.org/its/index.c= > gi?findid=3D9175</a><br> > <br> > Please remember to retain your issue tracking number (ITS#9175)<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><br clear=3D"all"><div><br></div>-- <br><div > dir=3D"ltr"= >> <div dir=3D"ltr"><div><div dir=3D"ltr"><div><div dir=3D"ltr"><p >> dir=3D"ltr= > " > style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bottom= > :0pt"><span > style=3D"font-size:13pt;font-family:Verdana;color:rgb(0,0,0);fo= > nt-weight:700;vertical-align:baseline;white-space:pre-wrap">Lexi Haley > </sp= an><span > style=3D"color:rgb(102,102,102);font-family:Verdana;font-size:13.3= > 333px;white-space:pre-wrap">(she/her/hers)</span></p><p dir=3D"ltr" style= > =3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt" > ><= span > style=3D"font-size:10pt;font-family:Verdana;color:rgb(102,102,102);ver= > tical-align:baseline;white-space:pre-wrap">Computer Scientist, System > Tools= , Advanced Technology Division</span></p><p dir=3D"ltr" > style=3D"color:rgb(= > 80,0,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span > style=3D"= > font-size:10pt;font-family:Verdana;color:rgb(102,102,102);vertical-align: > ba= seline;white-space:pre-wrap">Medical Information Technology, > Inc.</span></p= >> <p dir=3D"ltr" >> style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt= > ;margin-bottom:0pt"><span > style=3D"font-size:10pt;font-family:Verdana;color= > :rgb(102,102,102);vertical-align:baseline;white-space:pre-wrap">Office: > 781= -774-5156 | Mobile: 508-713-2499</span></p><p > style=3D"color:rgb(80,0,80);l= > ine-height:1.38;margin-top:0pt;margin-bottom:0pt"><font > face=3D"Verdana"><s= pan > style=3D"font-size:13.3333px;white-space:pre-wrap"><a href=3D"mailto:lh= > aley(a)meditech.com" > target=3D"_blank">lhaley(a)meditech.com</a></span></font><= /p><p > dir=3D"ltr" style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0= > pt;margin-bottom:0pt"><span > style=3D"font-size:10pt;font-family:Verdana;col= > or:rgb(102,102,102);vertical-align:baseline;white-space:pre-wrap">MEDITEC > H = Circle, Westwood, MA 02090</span></p><p dir=3D"ltr" > style=3D"color:rgb(80,0= > ,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span > style=3D"font= > -size:10pt;font-family:Verdana;color:rgb(102,102,102);vertical-align:base > li= ne;white-space:pre-wrap">Main: 781-821-3000 | Fax: > 781-821-2199</span></p><= /div></div></div></div></div></div> > </blockquote></div><br clear=3D"all"><div><br></div>-- <br><div > dir=3D"ltr"= >> <div dir=3D"ltr"><div><div dir=3D"ltr"><div><div dir=3D"ltr"><p >> dir=3D"ltr= > " > style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bottom= > :0pt"><span > style=3D"font-size:13pt;font-family:Verdana;color:rgb(0,0,0);fo= > nt-weight:700;vertical-align:baseline;white-space:pre-wrap">Lexi Haley > </sp= an><span > style=3D"color:rgb(102,102,102);font-family:Verdana;font-size:13.3= > 333px;white-space:pre-wrap">(she/her/hers)</span></p><p dir=3D"ltr" style= > =3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt" > ><= span > style=3D"font-size:10pt;font-family:Verdana;color:rgb(102,102,102);ver= > tical-align:baseline;white-space:pre-wrap">Computer Scientist, System > Tools= , Advanced Technology Division</span></p><p dir=3D"ltr" > style=3D"color:rgb(= > 80,0,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span > style=3D"= > font-size:10pt;font-family:Verdana;color:rgb(102,102,102);vertical-align: > ba= seline;white-space:pre-wrap">Medical Information Technology, > Inc.</span></p= >> <p dir=3D"ltr" >> style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt= > ;margin-bottom:0pt"><span > style=3D"font-size:10pt;font-family:Verdana;color= > :rgb(102,102,102);vertical-align:baseline;white-space:pre-wrap">Office: > 781= -774-5156 | Mobile: 508-713-2499</span></p><p > style=3D"color:rgb(80,0,80);l= > ine-height:1.38;margin-top:0pt;margin-bottom:0pt"><font > face=3D"Verdana"><s= pan > style=3D"font-size:13.3333px;white-space:pre-wrap"><a href=3D"mailto:lh= > aley(a)meditech.com" > target=3D"_blank">lhaley(a)meditech.com</a></span></font><= /p><p > dir=3D"ltr" style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0= > pt;margin-bottom:0pt"><span > style=3D"font-size:10pt;font-family:Verdana;col= > or:rgb(102,102,102);vertical-align:baseline;white-space:pre-wrap">MEDITEC > H = Circle, Westwood, MA 02090</span></p><p dir=3D"ltr" > style=3D"color:rgb(80,0= > ,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span > style=3D"font= > -size:10pt;font-family:Verdana;color:rgb(102,102,102);vertical-align:base > li= ne;white-space:pre-wrap">Main: 781-821-3000 | Fax: > 781-821-2199</span></p><= /div></div></div></div></div></div> > </blockquote></div><br clear=3D"all"><div><br></div>-- <br><div > dir=3D"ltr"= class=3D"gmail_signature"><div dir=3D"ltr"><div><div > dir=3D"ltr"><div><div= dir=3D"ltr"><p dir=3D"ltr" > style=3D"color:rgb(80,0,80);line-height:1.38;ma= > rgin-top:0pt;margin-bottom:0pt"><span > style=3D"font-size:13pt;font-family:V= > erdana;color:rgb(0,0,0);font-weight:700;vertical-align:baseline;white-spa > ce= :pre-wrap">Lexi Haley </span><span > style=3D"color:rgb(102,102,102);font-fam= > ily:Verdana;font-size:13.3333px;white-space:pre-wrap">(she/her/hers)</spa > n>= </p><p dir=3D"ltr" > style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:= > 0pt;margin-bottom:0pt"><span > style=3D"font-size:10pt;font-family:Verdana;co= > lor:rgb(102,102,102);vertical-align:baseline;white-space:pre-wrap">Comput > er= Scientist, System Tools, Advanced Technology Division</span></p><p > dir=3D"= ltr" > style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bot= > tom:0pt"><span > style=3D"font-size:10pt;font-family:Verdana;color:rgb(102,10= > 2,102);vertical-align:baseline;white-space:pre-wrap">Medical Information > Te= chnology, Inc.</span></p><p dir=3D"ltr" > style=3D"color:rgb(80,0,80);line-he= > ight:1.38;margin-top:0pt;margin-bottom:0pt"><span > style=3D"font-size:10pt;f= > ont-family:Verdana;color:rgb(102,102,102);vertical-align:baseline;white-s > pa= ce:pre-wrap">Office: 781-774-5156 | Mobile: 508-713-2499</span></p><p > style= > =3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt" > ><= font face=3D"Verdana"><span > style=3D"font-size:13.3333px;white-space:pre-wr= ap"><a > href=3D"mailto:lhaley@meditech.com" target=3D"_blank">lhaley@meditec= > h.com</a></span></font></p><p dir=3D"ltr" > style=3D"color:rgb(80,0,80);line-= > height:1.38;margin-top:0pt;margin-bottom:0pt"><span > style=3D"font-size:10pt= > ;font-family:Verdana;color:rgb(102,102,102);vertical-align:baseline;white > -s= pace:pre-wrap">MEDITECH Circle, Westwood, MA 02090</span></p><p > dir=3D"ltr"= > style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-botto > m:= 0pt"><span > style=3D"font-size:10pt;font-family:Verdana;color:rgb(102,102,10= > 2);vertical-align:baseline;white-space:pre-wrap">Main: 781-821-3000 | > Fax: = 781-821-2199</span></p></div></div></div></div></div></div> > > <br> > <a href=3D"https://ehr.meditech.com/expanse" target=3D"_blank"><img > src=3D"= > https://home.meditech.com/en/d/home/images/meditechemailsignaturelogo2018 > ex= panse.jpg"></a><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a > href=3D"ht= tps://www.linkedin.com/company/meditech" > target=3D"_blank"><img src=3D"http= > s://home.meditech.com/en/d/home/images/emailsignaturelinkedin20pixels.gif > " = style=3D"font-size:1.3em"></a><span style=3D"font-size:1.3em">=C2=A0 > </span= >> <a href=3D"https://twitter.com/MEDITECH" target=3D"_blank"><img >> src=3D"htt= > ps://home.meditech.com/en/d/home/images/emailsignaturetwitter20pixels.gif > " = style=3D"font-size:1.3em"></a><span > style=3D"font-size:1.3em">=C2=A0=C2=A0<= /span><a > href=3D"https://www.facebook.com/MeditechEHR" target=3D"_blank"><i= mg > src=3D"https://home.meditech.com/en/d/home/images/emailsignaturefacebook= > 20pixels.gif" style=3D"font-size:1.3em"></a></div><div><div><a > href=3D"http= > s://info.meditech.com/get-great-meditech-content?hsCtaTracking=3D864299ec > -5= abf-4004-9c6d-2d051794101f%7Cc911be42-538a-4a48-8dca-a6d4001c6326" > target= =3D"_blank"><span > style=3D"font-size:10pt;font-family:Verdana;color:rgb(17,= > 85,204);vertical-align:baseline;white-space:pre-wrap">Subscribe</span></a > ><= span > style=3D"font-size:10pt;font-family:Verdana;vertical-align:baseline;wh= > ite-space:pre-wrap"> </span><span > style=3D"font-size:10pt;font-family:Verda= > na;color:rgb(102,102,102);vertical-align:baseline;white-space:pre-wrap">t > o = receive emails from MEDITECH or to change email > preferences.</span></div></= div> > --0000000000003b4d37059f1c0189-- > > > -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

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