openldap-bugs February 2023

openldap-bugs@openldap.org

2 participants
190 discussions

[Issue 9564] New: Race condition with freeing the spilled pages from transaction
by openldap-its＠openldap.org 04 Nov '25

04 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=9564 Issue ID: 9564 Summary: Race condition with freeing the spilled pages from transaction Product: LMDB Version: 0.9.29 Hardware: Other OS: Mac OS Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: kriszyp(a)gmail.com Target Milestone: --- Created attachment 825 --> https://bugs.openldap.org/attachment.cgi?id=825&action=edit Free the spilled pages and dirty overflows before unlocking the write mutex The spilled pages (a transaction's mt_spill_pgs) is freed *after* a write transaction's mutex is unlocked (in mdb.master3). This can result in a race condition where a second transaction can start and subsequently assign a new mt_spill_pgs list to the transaction structure that it reuses. If this occurs after the first transaction unlocks the mutex, but before it performs the free operation on mt_spill_pgs, then the first transaction will end up calling a free on the same spilled page list as the second transaction, resulting in a double free (and crash). It would seem to be an extremely unlikely scenario to actually happen, since the free call is literally the next operation after the mutex is unlocked, and the second transaction would need to make it all the way to the point of saving the freelist before a page spill list is likely to be allocated. Consequently, this probably has rarely happened. However, one of our users (see https://github.com/DoctorEvidence/lmdb-store/issues/48 for the discussion) has noticed this occurring, and it seems that it may be particularly likely to happen on MacOS on the new M1 silicon. Perhaps there is some peculiarity to how the threads are more likely to yield execution after a mutex unlock, I am not sure. I was able to reproduce the issue by intentionally manipulating the timing (sleeping before the free) to verify that the race condition is technically feasible, and apparently this can happen "in the wild" on MacOS, at least with an M1. It is also worth noting that this is due to (or a regression from) the fix for ITS#9155 (https://github.com/LMDB/lmdb/commit/cb256f409bb53efeda4ac69ee8165a0b4fc1a277) where the free call was moved outside the conditional (for having a parent) that had previously never been executed after the mutex is unlocked, but now is called after the unlock. Anyway, the solution is relatively simple, the free call simply has to be moved above the unlock. In my patch, I also moved the free call for mt_dirty_ovs. I am not sure what OVERFLOW_NOTYET/mt_dirty_ovs is for, but presumably it should be handled the same. This could alternately be solved by saving the reference to these lists before unlocking, and freeing after unlocking, which would slightly decrease the amount of processing within the mutex guarded code. Let me know if you prefer a patch that does that. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9849] New: Update website to support LTS and Feature releases
by openldap-its＠openldap.org 15 Jul '25

15 Jul '25

https://bugs.openldap.org/show_bug.cgi?id=9849 Issue ID: 9849 Summary: Update website to support LTS and Feature releases Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: mnormann(a)symas.com Target Milestone: --- Modify .wlmrc variable names and website content to handle both Feature Release and Long Term Support release. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9934] New: slapd-config(5) should document how to store certificates for slapd usage
by openldap-its＠openldap.org 22 May '25

22 May '25

https://bugs.openldap.org/show_bug.cgi?id=9934 Issue ID: 9934 Summary: slapd-config(5) should document how to store certificates for slapd usage Product: OpenLDAP Version: 2.5.13 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Commit 7b41feed83b expanded the ability of cn=config to save the certificates used for TLS by slapd directly in the config database. However the documentation for the new parameters was never added to the slapd-config(5) man page. olcTLSCACertificate $ olcTLSCertificate $ olcTLSCertificateKey -- You are receiving this mail because: You are on the CC list for the issue.

1 13

[Bug 9245] New: devel/programming needs rewrite
by openldap-its＠openldap.org 28 Jan '25

28 Jan '25

https://bugs.openldap.org/show_bug.cgi?id=9245 Bug ID: 9245 Summary: devel/programming needs rewrite Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The information on the devel/programming web page is at least a decade out of date and needs a complete overhaul. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Issue 9827] New: Feature request for module argon2.so to support Argon2i, Argon2d, Argon2id
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=9827 Issue ID: 9827 Summary: Feature request for module argon2.so to support Argon2i, Argon2d, Argon2id Product: OpenLDAP Version: 2.6.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: juergen.sprenger(a)swisscom.com Target Milestone: --- Hi, This is a feature request. I would like to be able to chooses between Argon2i, Argon2d and Argon2id in slappasswd like in argon2 command: # argon2 Usage: argon2 [-h] salt [-i|-d|-id] [-t iterations] [-m log2(memory in KiB) | -k memory in KiB] [-p parallelism] [-l hash length] [-e|-r] [-v (10|13)] Password is read from stdin Parameters: salt The salt to use, at least 8 characters -i Use Argon2i (this is the default) -d Use Argon2d instead of Argon2i -id Use Argon2id instead of Argon2i -t N Sets the number of iterations to N (default = 3) -m N Sets the memory usage of 2^N KiB (default 12) -k N Sets the memory usage of N KiB (default 4096) -p N Sets parallelism to N threads (default 1) -l N Sets hash output length to N bytes (default 32) -e Output only encoded hash -r Output only the raw bytes of the hash -v (10|13) Argon2 version (defaults to the most recent version, currently 13) -h Print argon2 usage Example: /usr/local/etc/openldap # /usr/sbin/slappasswd -h "{ARGON2}" -o module-load="argon2.so i" -s secret /usr/local/etc/openldap # /usr/sbin/slappasswd -h "{ARGON2}" -o module-load="argon2.so d" -s secret /usr/local/etc/openldap # /usr/sbin/slappasswd -h "{ARGON2}" -o module-load="argon2.so id" -s secret Best regards Juergen Sprenger -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9952] New: Crash on exit with OpenSSL 3
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=9952 Issue ID: 9952 Summary: Crash on exit with OpenSSL 3 Product: OpenLDAP Version: 2.6.2 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: artur.zaprzala(a)gmail.com Target Milestone: --- A program using libldap will crash on exit after using SSL connection. How to reproduce on CentOS 9: Uncomment the following lines in /etc/pki/tls/openssl.cnf: [provider_sect] legacy = legacy_sect [legacy_sect] activate = 1 Run the command (you must enter a valid LDAP server address): python3 -c "import ldap; ldap.initialize('ldaps://<LDAP SERVER ADDRESS>').whoami_s()" Another example (no server required): python3 -c "import ctypes; ctypes.CDLL('libldap.so.2').ldap_pvt_tls_init_def_ctx(0)" Results: Segmentation fault (core dumped) Backtrace from gdb: Program received signal SIGSEGV, Segmentation fault. 0 ___pthread_rwlock_rdlock (rwlock=0x0) at pthread_rwlock_rdlock.c:27 1 0x00007ffff7c92f3d in CRYPTO_THREAD_read_lock (lock=<optimized out>) at crypto/threads_pthread.c:85 2 0x00007ffff7c8b126 in ossl_lib_ctx_get_data (ctx=0x7ffff7eff540 <default_context_int.lto_priv>, index=1, meth=0x7ffff7eb8a00 <provider_store_method.lto_priv>) at crypto/context.c:398 3 0x00007ffff7c98bea in get_provider_store (libctx=<optimized out>) at crypto/provider_core.c:334 4 ossl_provider_deregister_child_cb (handle=0x5555555ed620) at crypto/provider_core.c:1752 5 0x00007ffff7c8bf2f in ossl_provider_deinit_child (ctx=0x5555555d2650) at crypto/provider_child.c:279 6 OSSL_LIB_CTX_free (ctx=0x5555555d2650) at crypto/context.c:283 7 OSSL_LIB_CTX_free (ctx=0x5555555d2650) at crypto/context.c:276 8 0x00007ffff7634af6 in legacy_teardown (provctx=0x5555555ee9f0) at providers/legacyprov.c:168 9 0x00007ffff7c9901b in ossl_provider_teardown (prov=0x5555555ed620) at crypto/provider_core.c:1477 10 ossl_provider_free (prov=0x5555555ed620) at crypto/provider_core.c:683 11 0x00007ffff7c63956 in ossl_provider_free (prov=<optimized out>) at crypto/provider_core.c:668 12 evp_cipher_free_int (cipher=0x555555916c10) at crypto/evp/evp_enc.c:1632 13 EVP_CIPHER_free (cipher=0x555555916c10) at crypto/evp/evp_enc.c:1647 14 0x00007ffff7a6bc1d in ssl_evp_cipher_free (cipher=0x555555916c10) at ssl/ssl_lib.c:5925 15 ssl_evp_cipher_free (cipher=0x555555916c10) at ssl/ssl_lib.c:5915 16 SSL_CTX_free (a=0x555555ec1020) at ssl/ssl_lib.c:3455 17 SSL_CTX_free (a=0x555555ec1020) at ssl/ssl_lib.c:3392 18 0x00007fffe95edb89 in ldap_int_tls_destroy (lo=0x7fffe9616000 <ldap_int_global_options>) at /usr/src/debug/openldap-2.6.2-1.el9_0.x86_64/openldap-2.6.2/libraries/libldap/tls2.c:104 19 0x00007ffff7fd100b in _dl_fini () at dl-fini.c:138 20 0x00007ffff7873475 in __run_exit_handlers (status=0, listp=0x7ffff7a11658 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:113 21 0x00007ffff78735f0 in __GI_exit (status=<optimized out>) at exit.c:143 22 0x00007ffff785be57 in __libc_start_call_main (main=main@entry=0x55555556aa20 <main>, argc=argc@entry=4, argv=argv@entry=0x7fffffffe2b8) at ../sysdeps/nptl/libc_start_call_main.h:74 23 0x00007ffff785befc in __libc_start_main_impl (main=0x55555556aa20 <main>, argc=4, argv=0x7fffffffe2b8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe2a8) at ../csu/libc-start.c:409 24 0x000055555556b575 in _start () The problem is that ldap_int_tls_destroy() is called after the clean up of libssl. On program exit, at first default_context_int is cleaned up (OPENSSL_cleanup() was registered with atexit()): 0 ossl_lib_ctx_default_deinit () at crypto/context.c:196 1 OPENSSL_cleanup () at crypto/init.c:424 2 OPENSSL_cleanup () at crypto/init.c:338 3 0x00007ffff7873475 in __run_exit_handlers (status=0, listp=0x7ffff7a11658 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:113 4 0x00007ffff78735f0 in __GI_exit (status=<optimized out>) at exit.c:143 5 0x00007ffff785be57 in __libc_start_call_main (main=main@entry=0x55555556aa20 <main>, argc=argc@entry=4, argv=argv@entry=0x7fffffffe2c8) at ../sysdeps/nptl/libc_start_call_main.h:74 6 0x00007ffff785befc in __libc_start_main_impl (main=0x55555556aa20 <main>, argc=4, argv=0x7fffffffe2c8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe2b8) at ../csu/libc-start.c:409 7 0x000055555556b575 in _start () Then ossl_lib_ctx_get_data() tries to use default_context_int.lock, which is NULL. ldap_int_tls_destroy() is called by ldap_int_destroy_global_options(), registered by "__attribute__ ((destructor))". It seems that shared library destructors are always called before functions registered with atexit(). A solution may be to modify libraries/libldap/init.c to use atexit() instead of "__attribute__ ((destructor))". atexit() manual page says: "Since glibc 2.2.3, atexit() can be used within a shared library to establish functions that are called when the shared library is unloaded.". Functions registered with atexit() are called in the reverse order of their registration, so libssl must by initialized before libldap. If the order is wrong, libldap should detect it somehow and exit with abort(). -- You are receiving this mail because: You are on the CC list for the issue.

1 29

[Issue 9920] New: MDB_PAGE_FULL with master3 (encryption) because there is no room for the authentication data (MAC)
by openldap-its＠openldap.org 25 Oct '24

25 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9920 Issue ID: 9920 Summary: MDB_PAGE_FULL with master3 (encryption) because there is no room for the authentication data (MAC) Product: LMDB Version: unspecified Hardware: x86_64 OS: Mac OS Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: info(a)parlepeuple.fr Target Milestone: --- Created attachment 915 --> https://bugs.openldap.org/attachment.cgi?id=915&action=edit proposed patch Hello, on master3, using the encryption at rest feature, I am testing as follow: - on a new named database, i set the encryption function with mdb_env_set_encrypt(env, encfunc, &enckey, 32) - note that I chose to have a size parameter (The size of authentication data in bytes, if any. Set this to zero for unauthenticated encryption mechanisms.) of 32 bytes. - I add 2 entries on the DB, trying to saturate the first page. I chose to add a key of 33 Bytes and a value of 1977 Bytes, so the size of each node is 2010 Bytes (obviously the 2 keys are different). - This passes and the DB has just one leaf_pages, no overflow_pages, no branch_pages, an a depth of 1. - If I add one byte to the values I insert (starting again from a blank DB), then , instead of seeing 2 overflow_pages, I get an error : MDB_PAGE_FULL. - this clearly should not have happened. - Here is some tracing : add to leaf page 2 index 0, data size 48 key size 7 [74657374646200] add to leaf page 3 index 0, data size 1978 key size 33 [000000000000000000000000000000000000000000000000000000000000000000] add to branch page 5 index 0, data size 0 key size 0 [null] add to branch page 5 index 1, data size 0 key size 33 [000000000000000000000000000000000000000000000000000000000000000000] add to leaf page 4 index 0, data size 1978 key size 33 [000000000000000000000000000000000000000000000000000000000000000000] add to leaf page 4 index 1, data size 1978 key size 33 [020202020202020202020202020202020202020202020202020202020202020202] not enough room in page 4, got 1 ptrs upper-lower = 2020 - 2 = 2016 node size = 2020 Looking at the code, I understand that there is a problem at line 9005 : } else if (node_size + data->mv_size > mc->mc_txn->mt_env->me_nodemax) { where me_nodemax is incorrect, as it is not taking into account that some bytes will be needed for the MAC authentication code, which size is in env->me_esumsize. me_nodemax is calculated at line 5349: env->me_nodemax = (((env->me_psize - PAGEHDRSZ ) / MDB_MINKEYS) & -2) - sizeof(indx_t); So I substract me_esumsize with a "- env->me_esumsize" here: env->me_nodemax = (((env->me_psize - PAGEHDRSZ - env->me_esumsize) / MDB_MINKEYS) & -2) - sizeof(indx_t); I also substract it from me_maxfree_1pg in the line above, and in pmax in line 10435. I do not know if my patch is correct, but it solves the issue. Maybe there are other places in the code where the me_esumsize should be substracted from the available size. By example, when calculating the number of overflow pages in OVPAGES, it does not take into account me_esumsize, but I think it is ok, because there is only one MAC for the entire set of OV pages, and there is room for it in the first OV page. See the attached proposed patch. -- You are receiving this mail because: You are on the CC list for the issue.

1 40

[Issue 9982] New: Linker error when building with LDAP_CONNECTIONLESS
by openldap-its＠openldap.org 22 Oct '24

22 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9982 Issue ID: 9982 Summary: Linker error when building with LDAP_CONNECTIONLESS Product: OpenLDAP Version: 2.6.3 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: invokesus+openldap(a)gmail.com Target Milestone: --- Created attachment 942 --> https://bugs.openldap.org/attachment.cgi?id=942&action=edit Build log I'm encountering the following linker error when building from the master branch, with LDAP_CONNECTIONLESS defined. /nix/store/jbnmj9fljgnfyc1iswnrpfhlkpnnwiii-binutils-2.39/bin/ld: ./.libs/libldap.so: undefined reference to `ber_sockbuf_io_udp' Seems to have been happening since https://git.openldap.org/openldap/openldap/-/commit/4a87d7aad200aaa91cb0cb8…. Attaching the full build log. Also, attaching in the next update, a patch to fix the error. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9356] New: Add list of peerSIDs to consumer cookie to reduce cross traffic
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9356 Issue ID: 9356 Summary: Add list of peerSIDs to consumer cookie to reduce cross traffic Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- If we add a list of peersids to the cookie, each consumer can tell the providers who else the consumers talk to and then the provider can omit sending updates to that consumer, originating from those peers There's some special handling needed if a connection dies If a consumer loses one of its peer connections, and after N retries is still not connected, it should send a new cookie to its remaining peers saying "here's my new peer list" with the missing one removed. Likewise, if a retry eventually connects again, it can send a new cookie again Make that peer list reset configurable in the syncrepl config stanza. This can help account for end admin knowledge that some links may be more or less stable than other ones. The idea here is that if one of your other peers can still see the missing peer, they can start routing updates to you again It should abandon all existing persist sessions and send a new sync search with the new cookie to all remaining peers For consumer side, also means adding the sid for a given provider into the syncrepl stanza to save on having to try and discover the peer sid. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Bug 9219] New: Streamline tool API for 2.5
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9219 Bug ID: 9219 Summary: Streamline tool API for 2.5 Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The current tool API is a mess and needs fixing for 2.5. This affects things like slapacl (The fix for bug#7920 was a kludge to deal with this, needs revisiting). -- You are receiving this mail because: You are on the CC list for the bug.

1 7

← Newer
1
...
6
7
8
9
10
11
12
...
19
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2023