openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#9097) lmdb: premature free of env->me_txn0
by hyc＠symas.com 15 Oct '19

15 Oct '19

christopher(a)gmerlin.de wrote: > Full_Name: Christopher Zimmermann > Version: lmdb 0.9.24 > OS: OpenBSD > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (85.212.180.240) > > > Hi, > > I can reliably hit a Bus error on OpenBSD. > This is triggered by OpenBSDs malloc/free junking [1] and a use-after-free bug > in lmdb. > > Steps to reproduce: > - begin a read/write transaction (getting env->me_txn0) > - fill the environment > -> returns MDB_MAP_FULL > -> sets txn->mt_flags |= MDB_TXN_ERROR; (This is also env->me_txn0 !) > -> calls mdb_txn_abort ... > - abort the transaction (again) with mdb_abort() This is a bug in your code, you can't call txn_abort twice. This is already documented. Closing this ITS. -- -- 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

(ITS#9097) lmdb: premature free of env->me_txn0
by christopher＠gmerlin.de 15 Oct '19

15 Oct '19

Full_Name: Christopher Zimmermann Version: lmdb 0.9.24 OS: OpenBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.212.180.240) Hi, I can reliably hit a Bus error on OpenBSD. This is triggered by OpenBSDs malloc/free junking [1] and a use-after-free bug in lmdb. Steps to reproduce: - begin a read/write transaction (getting env->me_txn0) - fill the environment -> returns MDB_MAP_FULL -> sets txn->mt_flags |= MDB_TXN_ERROR; (This is also env->me_txn0 !) -> calls mdb_txn_abort -> calls mdb_txn_end(txn, MDB_END_ABORT|MDB_END_SLOT|MDB_END_FREE): mdb_txn_end tries not to free env->me_txn0: } else if (!F_ISSET(txn->mt_flags, MDB_TXN_FINISHED)) { [...] txn->mt_flags = MDB_TXN_FINISHED; if (!txn->mt_parent) { [...] mdb.c:3020 mode = 0; /* txn == env->me_txn0, do not free() it */ [...] } [...] } if (mode & MDB_END_FREE) free(txn); this prevents the free only for unfinished transactions. Unfinished transactions are now finished. - abort the transaction (again) with mdb_abort() -> calls mdb_txn_end(txn, MDB_END_ABORT|MDB_END_SLOT|MDB_END_FREE): since the env->me_txn0 detection is skipped on MDB_TXN_FINISHED transactions the transaction is freed, the memory will get "junked". - begin a read/write transaction (getting now invalid env->me_txn0) -> calls mdb_txn_renew0(env->me_txn0) MDB_env *env = txn->mt_env; /* txn->mt_env is now invalid */ MDB_txninfo *ti = env->me_txns; /* triggers bus error */ Please make the protection against freeing of me_txn0 more robust. Thanks, Christopher Zimmermann [1] https://man.openbsd.org/malloc#j

1 0

Re: (ITS#9091) mdb attribute get mixed up in slapadd continue (-c) mode
by maxime.besson＠worteks.com 14 Oct '19

14 Oct '19

On 10/14/19 8:47 PM, Howard Chu wrote: > > I'd also note that using -c has always been pretty risky. You would be better off using -j > in situations like this, as show below: > Thanks for the fix and tip!

1 0

Re: (ITS#9096)
by priit＠ww.ee 14 Oct '19

14 Oct '19

--0000000000009f14730594e762f7 Content-Type: text/plain; charset="UTF-8" [deemon@Zen ~]$ pkg-config --modversion lmdb 0.9.24 could this be the version number you are looking for? - Priit On Mon, 14 Oct 2019 at 20:27, Priit Oorn <priit(a)ww.ee> wrote: > Don't know the version or how to find out, but I zipped it for you so you > can maybe find out yourself? :-) > Or give me some hints how to find out with what command? > > - Priit > --0000000000009f14730594e762f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">[deemon@Zen ~]$ pkg-config --modversion lmdb<br>0.9.24<br>= <div><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_sig= nature"><br></div><div class=3D"gmail_signature" data-smartmail=3D"gmail_si= gnature">could this be the version number you are looking for?<br></div><di= v dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signature">= <br>- Priit</div></div><br></div><br><div class=3D"gmail_quote"><div dir=3D= "ltr" class=3D"gmail_attr">On Mon, 14 Oct 2019 at 20:27, Priit Oorn <<a = href=3D"mailto:priit@ww.ee">priit(a)ww.ee</a>> wrote:<br></div><blockquote= class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so= lid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Don't know= the version or how to find out, but I zipped it for you so you can maybe f= ind out yourself? :-)</div><div>Or give me some hints how to find out with = what command?<br></div><div><div><div><div dir=3D"ltr"><br>- Priit</div></d= iv></div></div></div> </blockquote></div> --0000000000009f14730594e762f7--

1 0

Re: (ITS#9091) mdb attribute get mixed up in slapadd continue (-c) mode
by hyc＠symas.com 14 Oct '19

14 Oct '19

Howard Chu wrote: > maxime.besson(a)worteks.com wrote: >> Full_Name: Maxime Besson >> Version: 2.4.48 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (77.193.139.162) >> >> >> I am attempting to implement the following disaster recovery process: >> >> * rm all previous data >> * run a configuration script (puppet) to recreate a bare-bones LDAP server and >> DIT >> * restore a backed-up slapcat dump on top of the freshly installed OpenLDAP >> server, ignoring duplicates already inserted by Puppet >> >> But it seems that when skipping over the existing objects, something goes wrong >> and causes attributes to get mixed up. But only when certain attributes are >> present in the existing objects. Here is how to reproduce: > > Thanks for the report and simple test case. This is now fixed in git master. I'd also note that using -c has always been pretty risky. You would be better off using -j in situations like this, as show below: >> >> puppet_init.ldif >> === >> dn: dc=example,dc=com >> objectClass: domain >> dc: example >> === >> >> backup.ldif >> === >> dn: dc=example,dc=com >> objectClass: domain >> dc: example >> contextCSN: 20190909094705.796552Z#000000#001#000000 >> >> dn: uid=ttully,dc=example,dc=com >> objectClass: inetOrgPerson >> uid: ttully >> userPassword:: c2Nob29uZXI= >> facsimileTelephoneNumber: +1 408 555 0111 >> givenName: Torrey >> cn: Torrey Tully >> telephoneNumber: +1 408 555 2274 >> sn: Tully >> roomNumber: 3924 >> mail: ttully(a)example.com >> l: Sunnyvale >> ou: Human Resources >> ou: People >> === >> >> When running the following commands: >> >> === >> rm -f /tmp/*.mdb >> slapadd -f slapd.conf puppet_init.ldif >> slapadd -f slapd.conf -c backup.ldif >> === slapadd -f slapd.conf -l puppet_init.ldif slapadd -f slapd.conf -l backup.ldif -j 5 -- -- 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#9091) mdb attribute get mixed up in slapadd continue (-c) mode
by hyc＠symas.com 14 Oct '19

14 Oct '19

maxime.besson(a)worteks.com wrote: > Full_Name: Maxime Besson > Version: 2.4.48 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (77.193.139.162) > > > I am attempting to implement the following disaster recovery process: > > * rm all previous data > * run a configuration script (puppet) to recreate a bare-bones LDAP server and > DIT > * restore a backed-up slapcat dump on top of the freshly installed OpenLDAP > server, ignoring duplicates already inserted by Puppet > > But it seems that when skipping over the existing objects, something goes wrong > and causes attributes to get mixed up. But only when certain attributes are > present in the existing objects. Here is how to reproduce: Thanks for the report and simple test case. This is now fixed in git master. > > > slapd.conf: > === > include /etc/ldap/schema/core.schema > include /etc/ldap/schema/cosine.schema > include /etc/ldap/schema/inetorgperson.schema > moduleload back_mdb > database mdb > maxsize 1073741824 > suffix "dc=example,dc=com" > directory /tmp > === > > > puppet_init.ldif > === > dn: dc=example,dc=com > objectClass: domain > dc: example > === > > backup.ldif > === > dn: dc=example,dc=com > objectClass: domain > dc: example > contextCSN: 20190909094705.796552Z#000000#001#000000 > > dn: uid=ttully,dc=example,dc=com > objectClass: inetOrgPerson > uid: ttully > userPassword:: c2Nob29uZXI= > facsimileTelephoneNumber: +1 408 555 0111 > givenName: Torrey > cn: Torrey Tully > telephoneNumber: +1 408 555 2274 > sn: Tully > roomNumber: 3924 > mail: ttully(a)example.com > l: Sunnyvale > ou: Human Resources > ou: People > === > > When running the following commands: > > === > rm -f /tmp/*.mdb > slapadd -f slapd.conf puppet_init.ldif > slapadd -f slapd.conf -c backup.ldif > === > > The redundant root object in backup.ldif gets skipped as -c should do, but the > attributes from my "ttully" user (and every following object in the ldif dump) > end up all mixed up: > > > === > slapcat -f slapd.conf > ... > dn: uid=ttully,dc=example,dc=com > objectClass: inetOrgPerson > userPassword:: dHR1bGx5 > facsimileTelephoneNumber: schooner > givenName: +1 408 555 0111 > cn: Torrey > telephoneNumber: Torrey Tully > sn: +1 408 555 2274 > roomNumber: Tully > mail: 3924 > l: ttully(a)example.com > ou: Sunnyvale > ou: Human Resources > ou: People > ... > === > > > This mixup does NOT happen if: > > * I import backup.ldif into an empty database > * OR I remove "contextCSN" from the backup ldif > * OR I use BDB instead of MDB > > So it seems that my issue is caused by a combination of MDB, skipping existing > entries, and having special attributes (contextCSN) in the skipped objects. > > I was able to reproduce this behavior: > * On Debian Buster (OpenLDAP 2.4.47) > * On RHEL7 + LTB project RPMs 2.4.48 > * Using a git snapshot (3be82f40d5cd4ca050e10859ecb961f28c807c41) with no > particular config options > * Using cn=config rather than slapd.conf > * On a real production system, rather than the simplified version presented > here. > * Using another "special" attribute such as pwdAccountLockedTime instead of > "contextCSN" > > > > -- -- 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#9096) tons of crashing and core dumps after every boot
by hyc＠symas.com 14 Oct '19

14 Oct '19

priit(a)ww.ee wrote: > Full_Name: Priit Oorn > Version: no idea > OS: Manjaro KDE stable > URL: https://bugsfiles.kde.org/attachment.cgi?id=123175 > Submission from: (NULL) (2001:7d0:8240:e600:7a6:c9cf:974a:2e6e) > > > STEPS TO REPRODUCE > 1. reboot system > 2. journalctl -p3 > > OBSERVED RESULT > KDE baloo_file and baloo_file_extr serial crashing due to LMDB crashing. > > EXPECTED RESULT > no services crashing obviously. > > SOFTWARE/OS VERSIONS > Linux/KDE Plasma: Manjaro Linux KDE stable > KDE Plasma Version: 5.16.5 > KDE Frameworks Version: 5.62.0 > Qt Version: 5.13.1 > LBDM version: no idea... that comes with Manjaro KDE stable default install + > all updates. the crashing thing has been there forever though over several > versions. > > reported the bug to KDE initially, but they say it's your fault... :P > https://bugs.kde.org/show_bug.cgi?id=412925 The stack traces you provided there https://bugsfiles.kde.org/attachment.cgi?id=123175 would indicate a crash in LMDB, but without providing version info we have nothing to go on. Nor do we have any insight into how KDE integrated LMDB and whether they used its API correctly. -- -- 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

(ITS#9096) tons of crashing and core dumps after every boot
by priit＠ww.ee 14 Oct '19

14 Oct '19

Full_Name: Priit Oorn Version: no idea OS: Manjaro KDE stable URL: https://bugsfiles.kde.org/attachment.cgi?id=123175 Submission from: (NULL) (2001:7d0:8240:e600:7a6:c9cf:974a:2e6e) STEPS TO REPRODUCE 1. reboot system 2. journalctl -p3 OBSERVED RESULT KDE baloo_file and baloo_file_extr serial crashing due to LMDB crashing. EXPECTED RESULT no services crashing obviously. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Manjaro Linux KDE stable KDE Plasma Version: 5.16.5 KDE Frameworks Version: 5.62.0 Qt Version: 5.13.1 LBDM version: no idea... that comes with Manjaro KDE stable default install + all updates. the crashing thing has been there forever though over several versions. reported the bug to KDE initially, but they say it's your fault... :P https://bugs.kde.org/show_bug.cgi?id=412925

1 0

Re: (ITS#9018) dynlist don't close connection
by quanah＠symas.com 14 Oct '19

14 Oct '19

Decoded we have: "I have changed back-meta to the back-ldap, and it resolved this problem." --On Tuesday, September 24, 2019 11:59 AM +0000 I.Harbuz(a)A1.by wrote: -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9095) back-mdb slapindex missing records
by hyc＠openldap.org 11 Oct '19

11 Oct '19

Full_Name: Howard Chu Version: 2.4 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.203.26.174) Submitted by: hyc In back-mdb the entry reindexer operates in batches of 500 entries at a time. (I.e., it commits one LMDB txn for every 500 entries.) But a final txn_commit is missing in tool_entry_close() to flush out the last few entries that were operated on.

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