- openldap-bugs - openldap.org

[Issue 9370] null-ptr dereference for unauthenticated packet in OpenLDAP slapd
by openldap-its＠openldap.org 02 Nov '20

02 Nov '20

https://bugs.openldap.org/show_bug.cgi?id=9370 --- Comment #3 from Salvatore Bonaccorso <carnil(a)debian.org> --- CVE-2020-25692 was assigned for this issue. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9383] Assertion failure in OpenLDAP: slapd v2.X - schema_init.c:certificateListValidate:419
by openldap-its＠openldap.org 02 Nov '20

02 Nov '20

https://bugs.openldap.org/show_bug.cgi?id=9383 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Group|OpenLDAP-devs | --- Comment #2 from Howard Chu <hyc(a)openldap.org> --- (In reply to phasip from comment #0) > A malicious packet can force OpenLDAP to fail an assertion and crash. > slapd: schema_init.c:419: int certificateListValidate(Syntax *, struct > berval *): Assertion `tag == LBER_INTEGER' failed. Note that this code was behind #ifdef LDAP_DEVEL so it is not vulnerable in any public OpenLDAP releases. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9372] New: Use POSIX semaphores by default on MacOS
by openldap-its＠openldap.org 30 Oct '20

30 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9372 Issue ID: 9372 Summary: Use POSIX semaphores by default on MacOS Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: kriszyp(a)gmail.com Target Milestone: --- Created attachment 775 --> https://bugs.openldap.org/attachment.cgi?id=775&action=edit Set POSIX semaphore as default for MacOS On Apple/MacOS, System V semaphores have a limit of 10 open robust (SEM_UNDO) semaphores at once per process, which can cause problems if a process has many open database environments/transactions open at once. Using POSIX semaphores eliminates this problems and supposedly have a little bit better performance. The attached patch (also at https://github.com/kriszyp/lmdb/commit/0971512f6a4aa5b05f99e481a6687d4802f7…) sets that as the default, and reverts back to System V semaphores with MDB_USE_ROBUST, since MacOS does not support robust POSIX locking. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9371] New: Compilation errors "unknown size" on VS/Windows
by openldap-its＠openldap.org 30 Oct '20

30 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9371 Issue ID: 9371 Summary: Compilation errors "unknown size" on VS/Windows Product: LMDB Version: unspecified Hardware: All OS: Windows Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: kriszyp(a)gmail.com Target Milestone: --- Created attachment 774 --> https://bugs.openldap.org/attachment.cgi?id=774&action=edit Patch to fix compilation errors Compiling with VS MSBuild.exe results in multiple compilation errors like: libraries\liblmdb\mdb.c(6569): error C2036: 'void *': unknown size Patch (based on mdb.master3) at https://github.com/kriszyp/lmdb/commit/12f1bdf9be5052728694eb5fa222688f50f8… (and attached) -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9364] New: Rework encryption API
by openldap-its＠openldap.org 30 Oct '20

30 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9364 Issue ID: 9364 Summary: Rework encryption API Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Currently a single initialization vector is set at env creation time, and is used for the entire life of the DB. Ideally it should be a value uniquely generated on every write to a page. The most straightforward approach would be to use a combination of the page number and txid. Even better would be to use a keyed hash of these two values. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 9377] New: Golang built-in race-detector tooling catching pointer arithmetic error on Win
by openldap-its＠openldap.org 27 Oct '20

27 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9377 Issue ID: 9377 Summary: Golang built-in race-detector tooling catching pointer arithmetic error on Win Product: LMDB Version: 0.9.25 Hardware: x86_64 OS: Windows Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: AskAlexSharov(a)gmail.com Target Milestone: --- Detector of race-conditions which built into Golang tooling shows next error on Windows x86_64: mdb.c:1487:7: char buf[MSGSIZE+PADSIZE], *ptr = buf; ^ fatal error: checkptr: pointer arithmetic computed bad pointer value Link to CI where error is reproducible: https://github.com/ledgerwatch/lmdb-go/pull/8/checks?check_run_id=131269917… -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9360] New: MDB_BAD_TXN: Transaction must abort, has a child, or is invalid
by openldap-its＠openldap.org 27 Oct '20

27 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9360 Issue ID: 9360 Summary: MDB_BAD_TXN: Transaction must abort, has a child, or is invalid Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: spam(a)markandruth.co.uk Target Milestone: --- I have 2 python scripts writing to a database (lmdb 0.9.26, py-lmdb 0.98) and 5-10 lua processes (with lightningmdb module which uses lmdb 0.9.22) which are long-running serving queries from the database. The database seems fine, not corrupted, and the python writes still working all the time. But periodically (perhaps 10-20% of the time), in a way I am unable to reliably reproduce, when the lua starts up every time a query is issued txn dbi_open returns "MDB_BAD_TXN: Transaction must abort, has a child, or is invalid". A direct restart of the processes does not fix this issue, however stopping lua+python and then starting again after a 5-20s wait usually fixes the issue. This has been reproduced over multiple servers but I'm at a loss as to how to debug this any further? -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9370] null-ptr dereference for unauthenticated packet in OpenLDAP slapd
by openldap-its＠openldap.org 26 Oct '20

26 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9370 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Group|OpenLDAP-devs | Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9368] New: openldap-2.4.54/contrib/slapd-modules/nssov/nssov.c:950:3: warning: Suss picious use of ; at the end of 'if' statement.
by openldap-its＠openldap.org 26 Oct '20

26 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9368 Issue ID: 9368 Summary: openldap-2.4.54/contrib/slapd-modules/nssov/nssov.c:95 0:3: warning: Suss picious use of ; at the end of 'if' statement. Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: dcb314(a)hotmail.com Target Milestone: --- Source code is if (ni->ni_socket >= 0); { if (close(ni->ni_socket)) Suggest drop ; -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9366] New: (async)meta does not check ldap_install_tls() return code
by openldap-its＠openldap.org 26 Oct '20

26 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9366 Issue ID: 9366 Summary: (async)meta does not check ldap_install_tls() return code Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- When SLAP_STARTTLS_ASYNCHRONOUS is defined, meta and asyncmeta backends do not make sure to save the ldap_install_tls() return code so a StartTLS set up error might not be detected properly and the connection might not be closed for a while. Patch coming. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9376] New: Repeated deletes with DUPSORT cursor breaks
by openldap-its＠openldap.org 26 Oct '20

26 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9376 Issue ID: 9376 Summary: Repeated deletes with DUPSORT cursor breaks Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- As discussed and fixed in https://git.openldap.org/openldap/openldap/-/merge_requests/194 -- You are receiving this mail because: You are on the CC list for the issue.

1 2

best ndis service provider in melbourne
by thebpogroup344＠gmail.com 25 Oct '20

25 Oct '20

I am a Medical Doctor in Australia and I am at this time specializing in Pediatrics. I am very loving about the work that I do. Our mission is to provide centered services with un-matched quality that support empowers permanent disable persons to make their own journey of life. As a support provider we help people with significant and permanent disability to achieve goals in their life by assisting in Community Participation, Household Tasks and many more. At Authentic Life Care, we provide home care support services to families, to assist them through challenging times in their lives. Here at Authentic Life Care, we set out our current arrangements for meeting the needs of customers who have significant and permanent disability. We maintain and improve current standards of accessibility to services for people with disabilities or those whose mobility is impaired. We will support independent travel as far as possible, with the principles of information and access elevated across the board so that clienteles with agility complications have more self-assurance in traveling. Get To Know More about us at https://authenticlifecare.com.au/

1 0

Loading freelist with large fragmented free space in LMDB
by Kris Zyp 24 Oct '20

24 Oct '20

I have noticed a performance issue with mdb_page_alloc loading the freelist while trying to find a large block when there is a significant amount of free-space that is fragmented/non-contiguous. In our application, we often have a database environment that may have a sub-database with large blocks (thousands of records around a MB), and another sub-database with many small blocks (10 of millions < 1KB). We frequently drop/delete the latter sub-database since it is an index of the former, to reindex it. However, this can leave multiple GBs of highly fragmented free space, and if we attempt to add/insert/put a record that is several MBs, mdb_page_alloc may attempt to load millions of free-page ids without finding a contiguous block. Loading large freelist seems to be an O(N^2) operation (N being size of free-list to load), since it repeatedly loads a constant size of new pages and rescans the whole cumulate IDL to search for blocks and merge new page ids (in mdb_midl_xmerge), and with very large free spaces, I've seen mdb_page_alloc take multiple minutes to complete. I think I have seen this with performing the database drop/delete as well. It seems like MDB_PARANOID may have been created to help deal with this type of issue. However, the Max_retries doesn't seem to be implemented/used by MDB_PARANOID. By adding a check to limit the retry variable to Max_retries (as seems intended), and compiling with MDB_PARANOID, I think this seems to mitigate this issue for us, and limits the free-space search so mdb_page_alloc always seems to return within a reasonable time. I was just curious if this was the intended way to deal with large free-spaces. And would it be helpful to (re?) implement the Max_retries (be glad to provide a patch) for when MDB_PARANOID is defined? Or is retry = num * 60 possibly a little bit high for a default retry setting? Or would it be preferable to improve the freelist loading to use a O(N*log N) algorithm (by possibly exponentially increasing size of blocks to load with binary tree merging) to load? Or is it better to consider this to be a pretty pathological case, and that that much free space (and record size variance) should be avoided, and that dropping/deleting such a large fragmented database should really be immediately followed by a copying the whole database environment with compaction to eliminate the excess (or all) free space? Anyway, I may be misunderstanding this issue, but my local use of MDB_PARANOID with the Max_retries fix seems like it is working fine for me (and I can certainly copy with compaction if I need to as well). Just curious if there are any suggestions otherwise, or any improvements that would be helpful to LMDB. Thanks, Kris

3 3

END
by Daniel Drinnon 23 Oct '20

23 Oct '20

END

3 2

[Issue 9373] New: Segmentation fault on ldap_simple_bind_s
by openldap-its＠openldap.org 22 Oct '20

22 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9373 Issue ID: 9373 Summary: Segmentation fault on ldap_simple_bind_s Product: OpenLDAP Version: 2.4.10 Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: ljin(a)microstrategy.com Target Milestone: --- Hit Faulting Signal: signal 11, Segmentation fault. when calling ldap_simple_bind_s. #0 0x00007f3e7cddec2d in poll () from /lib64/libc.so.6 #1 0x00007f3e468417d5 in ldap_result () from /usr/lib64/libldap_r-2.4.so.2 #2 0x00007f3e4684a808 in ldap_sasl_bind_s () from /usr/lib64/libldap_r-2.4.so.2 #3 0x00007f3e4684b055 in ldap_simple_bind_s () from /usr/lib64/libldap_r-2.4.so.2 This happened when there were multi-thread ldap_simple_bind_s calls. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9375] New: Segmentation fault on ldap_search_ext_s
by openldap-its＠openldap.org 22 Oct '20

22 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9375 Issue ID: 9375 Summary: Segmentation fault on ldap_search_ext_s Product: OpenLDAP Version: 2.4.44 Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: ljin(a)microstrategy.com Target Milestone: --- Hit Faulting Signal: signal 11, Segmentation fault in multi-threads environment. One crash call stack. #0 0x00007f08af05392b in ber_int_sb_write () from /lib64/liblber-2.4.so.2 #1 0x00007f08af04fc0b in ber_flush2 () from /lib64/liblber-2.4.so.2 #2 0x00007f08af281f71 in ldap_int_flush_request () from /lib64/libldap_r-2.4.so.2 #3 0x00007f08af282352 in ldap_send_server_request () from /lib64/libldap_r-2.4.so.2 #4 0x00007f08af2826da in ldap_send_initial_request () from /lib64/libldap_r-2.4.so.2 #5 0x00007f08af27153a in ldap_pvt_search () from /lib64/libldap_r-2.4.so.2 #6 0x00007f08af2716aa in ldap_pvt_search_s () from /lib64/libldap_r-2.4.so.2 #7 0x00007f08af271780 in ldap_search_ext_s () from /lib64/libldap_r-2.4.so.2 Another one: [0] /usr/lib64/liblber-2.4.so.2.10.7!ber_sockbuf_ctrl + 0x1ac [1] /usr/lib64/libldap_r-2.4.so.2.10.7!ldap_mark_select_clear + 0x2f [2] /usr/lib64/libldap_r-2.4.so.2.10.7!ldap_free_connection + 0x2b3 [3] /usr/lib64/libldap_r-2.4.so.2.10.7!ldap_int_bisect_insert + 0x4a5 [4] /usr/lib64/libldap_r-2.4.so.2.10.7!ldap_int_bisect_insert + 0x1bd [5] /usr/lib64/libldap_r-2.4.so.2.10.7!ldap_abandon_ext + 0x5a [6] /usr/lib64/libldap_r-2.4.so.2.10.7!ldap_abandon + 0x26 [7] /usr/lib64/libldap_r-2.4.so.2.10.7!ldap_pvt_search_s + 0xec [8] /usr/lib64/libldap_r-2.4.so.2.10.7!ldap_search_ext_s + 0x40 -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9374] New: Segmentation fault on ldap_ld_free
by openldap-its＠openldap.org 22 Oct '20

22 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9374 Issue ID: 9374 Summary: Segmentation fault on ldap_ld_free Product: OpenLDAP Version: 2.4.44 Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: ljin(a)microstrategy.com Target Milestone: --- Hit Faulting Signal: signal 11, Segmentation fault when multiple threads environment. #0 0x00007f13daa9b92b in ber_int_sb_write () from /lib64/liblber-2.4.so.2 #1 0x00007f13daa97c0b in ber_flush2 () from /lib64/liblber-2.4.so.2 #2 0x00007f13dacee6c7 in ldap_send_unbind () from /usr/lib64/libldap_r-2.4.so.2 #3 0x00007f13dacf700e in ldap_free_connection () from /usr/lib64/libldap_r-2.4.so.2 #4 0x00007f13dacee1bf in ldap_ld_free () from /usr/lib64/libldap_r-2.4.so.2 -- You are receiving this mail because: You are on the CC list for the issue.

1 2

Exhausting Locked SEM_UNDO Semaphores on MacOS
by Kris Zyp 20 Oct '20

20 Oct '20

In LMDB, if you attempt to open more than 10 transactions (on different environments) on one process on MacOS, then mdb_txn_begin will fail. This can be reproduced by opening 11 different database environments in one process, and calling mdb_txn_begin (as write transactions) on each one. The 11th one will return EINVAL. I believe this is because (on this OS, MacOS 10.13.6) the System V semaphores have a limit of 10 SEM_UNDO locked semaphores on one process. So when mdb_txn_begin attempts to open an 11th transaction, the mdb_sem_wait/semop call fails, returning EINVAL. I was testing with latest LMDB from mdb.master. Once I finally debugged this and figured out the issue, I have been able to work around it by compiling with MDB_USE_POSIX_SEM which seems to resolve the issue. But this still leaves a few questions: Is there any issue with compiling with MDB_USE_POSIX_SEM on MacOS? Would it be better if LMDB defaulted to this shared lock implementation for this OS? And/or would there be value in LMDB providing a more specific error message in this situation? The documentation doesn't indicate EINVAL as a possible return value for mdb_txn_begin, and this is a very generic error with little indication of the root problem, that was rather confusing to me, at least. Or is there an expectation that processes can only open a limited number of database environments (and have open transactions on them)? (Our server typically has about 30 environments open with about 2-16 dbs/env, with many concurrent transactions, without issue on other OSes.) I would be happy to put together a patch for this, but I am not sure of the reasons for the selection of the different shared lock implementations on different OSes. Anyway, I'd be glad to help contribute a patch if there is a specific way this should work. Thank you!

2 6

[Issue 9369] New: Logging based on severity
by openldap-its＠openldap.org 15 Oct '20

15 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9369 Issue ID: 9369 Summary: Logging based on severity Product: OpenLDAP Version: 2.4.46 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: gdb91(a)protonmail.com Target Milestone: --- Currently OpenLDAP logging can be controller per area (subsystem) for example "trace function calls" or "debug packet handling". It would be good to have logging based on severity levels such as INFO, DEBUG, ERROR, WARNING, CRITICAL, etc., something that could be set up at run time. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8820] ldap_get_attribute_ber() function needs to be documented
by openldap-its＠openldap.org 14 Oct '20

14 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=8820 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.5.0 |2.5.1 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8874] --with-fetch incorrectly links libcom_err
by openldap-its＠openldap.org 14 Oct '20

14 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=8874 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.5.0 |2.5.1 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8659] accesslog man page updates
by openldap-its＠openldap.org 14 Oct '20

14 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=8659 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.5.0 |2.5.1 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7129] slapo-valsort(5) missing description of LDAP_CONTROL_VALSORT
by openldap-its＠openldap.org 14 Oct '20

14 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=7129 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.5.0 |2.5.1 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8943] back-mdb: speed up parallel add/delete
by openldap-its＠openldap.org 14 Oct '20

14 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=8943 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.5.0 |2.5.1 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7295] Problem with TLS: threads and OpenSSL
by openldap-its＠openldap.org 14 Oct '20

14 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=7295 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.5.0 |2.5.1 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs