- openldap-bugs - openldap.org

[Issue 10517] New: mbedTLS doesn't verify certificate in reqcert try mode
by openldap-its＠openldap.org 05 Jun '26

05 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10517 Issue ID: 10517 Summary: mbedTLS doesn't verify certificate in reqcert try mode Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- When setting the authmode to OPTIONAL, mbedTLS documentation[0] says that it's the user's responsibility to check the verification result if they care. `reqcert try` does care, but mbedtls_ssl_get_verify_result is never called in that case and so an invalid cert is not detected (easy to test by changing line 204 in test067). [0]. https://os.mbed.com/teams/sandbox/code/mbedtls/docs/tip/ssl_8h.html#a569528… -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10509] New: 2.7: Feature notes for announcement file
by openldap-its＠openldap.org 04 Jun '26

04 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10509 Issue ID: 10509 Summary: 2.7: Feature notes for announcement file Product: OpenLDAP Version: unspecified 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: --- Add feature notes for the 2.7 announcement file -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10508] New: syncrepl: be_modrdn / message_to_op called without orm_no_opattrs=1, modifiersName clobbered by consumer rootdn
by openldap-its＠openldap.org 03 Jun '26

03 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10508 Issue ID: 10508 Summary: syncrepl: be_modrdn / message_to_op called without orm_no_opattrs=1, modifiersName clobbered by consumer rootdn Product: OpenLDAP Version: 2.6.13 Hardware: i386 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: apostnikov(a)gmail.com Target Milestone: --- Created attachment 1150 --> https://bugs.openldap.org/attachment.cgi?id=1150&action=edit 0001-syncrepl-set-orm_no_opattrs-for-backend-ops.patch When syncrepl applies provider changes locally it invokes the backend through be_add / be_modify / be_modrdn / be_delete, carrying the provider's operational attributes in the modlist. Without `op->orm_no_opattrs = 1` the backend (verified on back-mdb; servers/slapd/back-mdb/modrdn.c:76 and modify.c:619) calls slap_mods_opattrs(), which auto-injects a `replace modifiersName=<op->o_dn>` mod whenever modifiersName is not already present in the modlist. For syncrepl, `op->o_dn` is the consumer's local rootdn (set at syncrepl.c:2165 — `op->o_dn = op->o_bd->be_rootdn`), so the consumer ends up with `modifiersName=cn=<consumer-rootdn>` instead of the provider's value. ITS#4820 originally papered over this in syncrepl_diff_entry() with a kludge that always forced modifiersName/modifyTimestamp into the diff (`if (*mods && (modifiersName||modifyTimestamp)) attr_cmp(NULL,new)`). ITS#10250 commit 87933f3e removed that kludge with the rationale "the mod is being passed to the backend with orm_no_opattrs these days". But two code paths in syncrepl.c never actually set orm_no_opattrs: 1. syncrepl_entry() refresh-mode rename-with-content path (around line 4788 on master): the parallel be_modify branch sets `orm_no_opattrs = 1/0` around its call; the be_modrdn branch does not. 2. syncrepl_message_to_op() (delta-sync log replay; whole function from line 3180 on master): none of the four backend dispatches (be_add, be_modify, be_modrdn, be_delete) set the flag. Once 87933f3e removed the kludge, the auto-inject surfaced whenever provider and consumer happened to already agree on modifiersName so syncrepl_diff_entry produced no mod for it. Whether that happens for a given entry depends on attribute iteration order in the diff (attribute hash bucket order), which is why x86_64/aarch64 mostly mask the bug while x86/armv7/armhf/s390x (QEMU builders) trigger it deterministically and ppc64le sees it as flake in test063. Worst case the consumer ends up with the provider's entryCSN (the modrdn bumped it) but the wrong modifiersName, and ITS#10358's assert-retry then sees identical entryCSN, takes no further action, and the corruption is permanent until something else updates the entry. Reproducer ---------------------------------------------------------------- Native: 32-bit or big-endian build of HEAD; run cd tests make BACKEND=mdb mdb-mod TESTS=test017-syncreplication-refresh Cross-arch via Alpine's CI image (any host): docker run --rm --platform linux/386 -v $PWD:/mnt \ registry.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci:latest-x86 \ sh -c 'cd /mnt && ./configure --enable-modules --enable-mdb=mod \ --enable-syncprov=mod && make && cd tests && make mdb-mod' Expected on affected builders: >>>>> Starting test017-syncreplication-refresh for mdb... ... test failed - provider and consumer databases differ >>>>> Failed test017-syncreplication-refresh for mdb Capturing the diff (modify defines.sh's CMPOUT temporarily) shows: 348c348 < description: Example, Inc. ITS test domain --- > description: Example, Inc. modify+modrdn test domain 350c350 < modifiersName: cn=Manager,dc=example,dc=com --- > modifiersName: cn=consumer,dc=example,dc=com (Both entries carry the SAME final entryCSN — that's the smoking gun: the consumer adopted the provider's CSN via the modrdn, but the follow-up modify hit `err=122 LDAP_ASSERTION_FAILED` because of the CSN bump, and ITS#10358's retry then short-circuited.) Proposed fix ---------------------------------------------------------------- Six added lines in servers/slapd/syncrepl.c — see attached patch 0001-syncrepl-set-orm_no_opattrs-for-backend-ops.patch. Tested against OPENLDAP_REL_ENG_2_6_13: full make test suite passes on x86 (linux/386 QEMU) including all six tests that ITS#10250 patched plus test043-delta-syncrepl and test063-delta-multiprovider. References / related ITS ---------------------------------------------------------------- ITS#4820 — the original modifiersName/modifyTimestamp kludge added in 2007 ITS#10250 — kludge removed (MR#817, commit 87933f3e), exposing this bug ITS#10358 — assert-control retry (MR#781) — masks the divergence as silent data loss ITS#8852 — sorted_attr_cmp() prerequisite for ITS#10250 (commit 8986f99d) -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 10515] New: Miscellaneous Windows issues
by openldap-its＠openldap.org 03 Jun '26

03 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10515 Issue ID: 10515 Summary: Miscellaneous Windows issues Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Just opened this ticket to have some place to assign further fixes for issues on Windows. Both related to compilation and to running the test suite. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10353] New: No TLS connection on Windows because of missing ENOTCONN in socket.h
by openldap-its＠openldap.org 03 Jun '26

03 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10353 Issue ID: 10353 Summary: No TLS connection on Windows because of missing ENOTCONN in socket.h Product: OpenLDAP Version: 2.6.10 Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: julien.wadel(a)belledonne-communications.com Target Milestone: --- On Windows, the TLS connection cannot be done and we get the connection error: Can't contact LDAP server. => Connections are done with WSAGetLastError(). After getting WSAEWOULDBLOCK, the connection is not restart because of the state WSAENOTCONN that is not known. OpenLDAP use ENOTCONN that is set to 126 by "ucrt/errno.h" while WSAENOTCONN is 10057L. Adding #define ENOTCONN WSAENOTCONN like for EWOULDBLOCK resolve the issue. Reference commit on external project: https://gitlab.linphone.org/BC/public/external/openldap/-/commit/62fbfb12e8… -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9739] New: Undefined reference to ber_sockbuf_io_udp in 2.6.0
by openldap-its＠openldap.org 03 Jun '26

03 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=9739 Issue ID: 9739 Summary: Undefined reference to ber_sockbuf_io_udp in 2.6.0 Product: OpenLDAP Version: 2.6.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: simon.pichugin(a)gmail.com Target Milestone: --- While I was trying to build OpenLDAP 2.6 on Fedora Rawhide I've got the error message: /usr/bin/ld: ./.libs/libldap.so: undefined reference to `ber_sockbuf_io_udp' I've checked commits from https://bugs.openldap.org/show_bug.cgi?id=9673 and found that 'ber_sockbuf_io_udp' was not added to https://git.openldap.org/openldap/openldap/-/blob/master/libraries/liblber/… I've asked on the project's mailing list and got a reply: "That symbol only exists if OpenLDAP is built with LDAP_CONNECTIONLESS defined, which is not a supported feature. Feel free to file a bug report at https://bugs.openldap.org/" https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/… Hence, creating the bug. -- You are receiving this mail because: You are on the CC list for the issue.

1 20

[Issue 10514] New: another mutex bug in back-monitor
by openldap-its＠openldap.org 03 Jun '26

03 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10514 Issue ID: 10514 Summary: another mutex bug in back-monitor Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Same as #1710 but introduced later in 127ac65c447b8d28ba3cd75e1b8cee28006d5472 Calling mutex_destroy on a locked mutex in cache.c:314 monitor_cache_remove(). -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10516] New: dynamic backends don't get rebuilt
by openldap-its＠openldap.org 02 Jun '26

02 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10516 Issue ID: 10516 Summary: dynamic backends don't get rebuilt Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- The makefile rules need a small fix. -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 10513] New: slapd segfault during shutdown when syncrepl is in retry mode
by openldap-its＠openldap.org 02 Jun '26

02 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10513 Issue ID: 10513 Summary: slapd segfault during shutdown when syncrepl is in retry mode Product: OpenLDAP Version: 2.6.10 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: Marcelo.DeCastroLoebens(a)windriver.com Target Milestone: --- ## Problem slapd crashes with a segfault during shutdown. The crash occurs when the syncrepl provider is unreachable (syncrepl in retry mode). The issue has been observed twice under the same conditions. ## How to Reproduce 1. Configure slapd with syncrepl+TLS pointing to an unreachable host 2. Start slapd (syncrepl enters retry loop) 3. Send SIGTERM to slapd The crash is a race condition and does not occur often, but is reproducible with repeated attempts. ## Environment - OpenLDAP: 2.6.10 - OS: Debian 13 (Trixie), Linux 6.12, amd64 - OpenSSL: 3.5.1 - glibc: 2.41 ## Configuration slapd with back-mdb, syncrepl configured in refreshAndPersist mode with TLS, pointing to a provider that is unreachable (syncrepl in retry loop). mirrormode enabled, syncprov overlay loaded. Relevant slapd.conf excerpt: database mdb directory /var/lib/ldap syncrepl rid=000 provider=ldaps://peer-host tls_reqsan=demand type=refreshAndPersist retry="5 5 300 +" searchbase="dc=example,dc=local" bindmethod=simple binddn="cn=admin,dc=example,dc=local" credentials=secret mirrormode TRUE overlay syncprov ## Stack Traces Two threads crash simultaneously: Two threads crash simultaneously: Thread 1 (main thread, PID 6946): #0 0x00007fe467381d91 (libcrypto.so.3 + 0x137d91) #1 0x00007fe467382303 (libcrypto.so.3 + 0x138303) #2 0x00007fe467382133 (libcrypto.so.3 + 0x138133) #3 0x00007fe4673822a5 (libcrypto.so.3 + 0x1382a5) #4 0x00007fe467382133 (libcrypto.so.3 + 0x138133) #5 0x00007fe467382303 (libcrypto.so.3 + 0x138303) #6 0x00007fe467382133 (libcrypto.so.3 + 0x138133) #7 0x00007fe467382209 ASN1_item_free (libcrypto.so.3 + 0x138209) #8 0x00007fe467634ce9 X509_OBJECT_free (libcrypto.so.3 + 0x3eace9) #9 0x00007fe467601970 OPENSSL_sk_pop_free (libcrypto.so.3 + 0x3b7970) #10 0x00007fe46763528d X509_STORE_free (libcrypto.so.3 + 0x3eb28d) #11 0x00007fe4678c914e SSL_CTX_free (libssl.so.3 + 0x4614e) #12 0x0000563ee1c599b1 bindconf_free (/usr/sbin/slapd + 0x3d9b1) #13 0x0000563ee1ccf0e2 syncinfo_free (/usr/sbin/slapd + 0xb30e2) #14 0x0000563ee1c70d1c backend_destroy_one (/usr/sbin/slapd + 0x54d1c) #15 0x0000563ee1c70e6a backend_destroy (/usr/sbin/slapd + 0x54e6a) #16 0x0000563ee1c931c1 slap_destroy (/usr/sbin/slapd + 0x771c1) #17 0x0000563ee1c444c3 main (/usr/sbin/slapd + 0x284c3) #18 0x00007fe4679bbca8 (libc.so.6 + 0x29ca8) #19 0x00007fe4679bbd65 __libc_start_main (libc.so.6 + 0x29d65) #20 0x0000563ee1c45431 _start (/usr/sbin/slapd + 0x29431) Thread 2 (worker, TID 6948): #0 0x00007fe466dc9ae9 (back_mdb.so.2 + 0x29ae9) #1 0x00007fe467a22271 (libc.so.6 + 0x90271) #2 0x00007fe467a24a4e (libc.so.6 + 0x92a4e) #3 0x00007fe467aa27b8 (libc.so.6 + 0x1107b8) Kernel log: slapd[6948]: segfault at 7fe467c900c8 ip 00007fe466dc9ae9 sp 00007fe425bf4e80 error 7 in back_mdb.so.2.0.200 -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 8901] slapd segfaults in mdb_env_reader_dest
by openldap-its＠openldap.org 01 Jun '26

01 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=8901 --- Comment #10 from Howard Chu <hyc(a)openldap.org> --- (In reply to Marcelo.DeCastroLoebens from comment #9) > (In reply to Howard Chu from comment #8) > > Fix in https://git.openldap.org/openldap/openldap/-/merge_requests/888 > > please test. > > Thanks for the fix and the speedy replies. > > I will start testing the integration of this patch with our system. Will > need some time (can't say for sure how much) since the occurrence is low, I > will leave a test env cycling the shutdown over a bunch of times, then > report here the results. For reference, the direct way to verify this fix is to check for proper thread pool cleanup after throwing a bit of load at the server. I did this using test008 in the test suite. tests% ./run -k test008 The -k flag tells it not to kill slapd after the test finishes. Then attach to the server with gdb and set a breakpoint on the last line of the ldap_pvt_thread_pool_close() function. (tpool.c:907 with this patch). Then send slapd a signal to tell it to shutdown. When it hits the breakpoint, there should be no more threadpool worker threads left. I've tested on Linux and Windows and verified proper cleanup here. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8901] slapd segfaults in mdb_env_reader_dest
by openldap-its＠openldap.org 01 Jun '26

01 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=8901 --- Comment #9 from Marcelo.DeCastroLoebens(a)windriver.com --- (In reply to Howard Chu from comment #8) > Fix in https://git.openldap.org/openldap/openldap/-/merge_requests/888 > please test. Thanks for the fix and the speedy replies. I will start testing the integration of this patch with our system. Will need some time (can't say for sure how much) since the occurrence is low, I will leave a test env cycling the shutdown over a bunch of times, then report here the results. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10472] New: Detect servers dying during tests
by openldap-its＠openldap.org 01 Jun '26

01 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10472 Issue ID: 10472 Summary: Detect servers dying during tests Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: test suite Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Currently the test suite starts tests as background jobs and ignores when they exit prematurely or with a non-zero exit code. This makes it impossible to detect shutdown time crashes or enable any instrumentation/leak-checking tools. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 8901] slapd segfaults in mdb_env_reader_dest
by openldap-its＠openldap.org 30 May '26

30 May '26

https://bugs.openldap.org/show_bug.cgi?id=8901 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |IN_PROGRESS --- Comment #8 from Howard Chu <hyc(a)openldap.org> --- Fix in https://git.openldap.org/openldap/openldap/-/merge_requests/888 please test. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8901] slapd segfaults in mdb_env_reader_dest
by openldap-its＠openldap.org 29 May '26

29 May '26

https://bugs.openldap.org/show_bug.cgi?id=8901 --- Comment #7 from Howard Chu <hyc(a)openldap.org> --- (In reply to Marcelo.DeCastroLoebens from comment #6) > Thanks for the analysis and workaround provided. > > Do you have an opinion about the risk associated with the workaround? Since > I'm not familiar with the code, that would be very helpful. > > I don't have the expertise to comprehensive test slapd in isolation, so I > would like to know if you imagine possible side effects during "regular" > usage (not shutdown). There's no impact during regular use since ldap_pvt_thread_pool_close() is only called during shutdown. Actually, just to be more explicit - the sleep(1) should be inserted in slapd/daemon.c:slapd_daemon_task() right after its call to ldap_pvt_thread_pool_close(). There's no need to muck with libldap itself. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8901] slapd segfaults in mdb_env_reader_dest
by openldap-its＠openldap.org 29 May '26

29 May '26

https://bugs.openldap.org/show_bug.cgi?id=8901 --- Comment #6 from Marcelo.DeCastroLoebens(a)windriver.com --- Thanks for the analysis and workaround provided. Do you have an opinion about the risk associated with the workaround? Since I'm not familiar with the code, that would be very helpful. I don't have the expertise to comprehensive test slapd in isolation, so I would like to know if you imagine possible side effects during "regular" usage (not shutdown). -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8901] slapd segfaults in mdb_env_reader_dest
by openldap-its＠openldap.org 29 May '26

29 May '26

https://bugs.openldap.org/show_bug.cgi?id=8901 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|VERIFIED |CONFIRMED Resolution|FEEDBACK |--- --- Comment #5 from Howard Chu <hyc(a)openldap.org> --- The problem is because ldap_pvt_thread_pool_close() doesn't actually know when the last thread has exited. The last thread does a cond_signal() to tell that it is exiting, but there's additional time between that and when the thread actually returns (or calls pthread_exit). And LMDB's own reader_dest function doesn't execute until the actual pthread_exit occurs. So when ldap_pvt_thread_pool_close() returns, worker threads may still be running. Then when backend_shutdown is called, which invokes back-mdb's shutdown and eventual mdb_env_close(), it may get there before the worker threads have completed, and so destroy the environment while worker threads are still trying to clear their reader slots. A proper fix would require some rewriting of the thread_pool code to track thread creation and termination explicitly. A workaround for now would be to insert a sleep(1) at the end of ldap_pvt_thread_pool_close(). -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8901] slapd segfaults in mdb_env_reader_dest
by openldap-its＠openldap.org 29 May '26

29 May '26

https://bugs.openldap.org/show_bug.cgi?id=8901 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Marcelo.DeCastroLoebens@win | |driver.com --- Comment #4 from Howard Chu <hyc(a)openldap.org> --- *** Issue 10513 has been marked as a duplicate of this issue. *** -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9716] New: Fix default guide versions for head and 2.6
by openldap-its＠openldap.org 26 May '26

26 May '26

https://bugs.openldap.org/show_bug.cgi?id=9716 Issue ID: 9716 Summary: Fix default guide versions for head and 2.6 Product: OpenLDAP Version: unspecified 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: --- The preamble file needs to be fixed in openldap head and the 2.6 release branch to be correct. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10507] New: Remove back-perl from OpenLDAP 2.7
by openldap-its＠openldap.org 26 May '26

26 May '26

https://bugs.openldap.org/show_bug.cgi?id=10507 Issue ID: 10507 Summary: Remove back-perl from OpenLDAP 2.7 Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- OpenLDAP 2.6 deprecated back-perl, so remove it from the 2.7 release branch -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10203] New: no pkgconfig file included for liblmdb
by openldap-its＠openldap.org 26 May '26

26 May '26

https://bugs.openldap.org/show_bug.cgi?id=10203 Issue ID: 10203 Summary: no pkgconfig file included for liblmdb Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: otto(a)drijf.net Target Milestone: --- liblmdb does not ship with a pkgconfig file. More and more build systems rely on presense of a pkgconfig file, so it would be nice if liblmdb installed oneone. An example: prefix=/usr/local exec_prefix=${prefix} libdir=${prefix}/lib includedir=${prefix}/include Name: lmdb Description: Lightning memory-mapped database: key-value data store URL: https://www.symas.com/symas-embedded-database-lmdb Version: 0.9.32 Libs: -L${libdir} -llmdb Cflags: -I${includedir} Thanks. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9009] 2.7: Switch to LMDB v1.0
by openldap-its＠openldap.org 26 May '26

26 May '26

https://bugs.openldap.org/show_bug.cgi?id=9009 --- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • aa02d9f5 by Howard Chu at 2026-05-22T03:51:12+01:00 ITS#9009 slapd-mdb: refix Makefile RE27: • 7ae0869b by Howard Chu at 2026-05-22T19:12:49+00:00 ITS#9009 slapd-mdb: refix Makefile -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10512] New: systemd exec - update to absolute path
by openldap-its＠openldap.org 26 May '26

26 May '26

https://bugs.openldap.org/show_bug.cgi?id=10512 Issue ID: 10512 Summary: systemd exec - update to absolute path Product: OpenLDAP Version: 2.6.10 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: daniel(a)iamniz.co.uk Target Milestone: --- Could the ExecStart option in the systemd unit file be updated to use a absolute path? ERROR:systemctl: slapd.service: Exec is not an absolute path: ExecStart=sh -c 'mkdir -p /run/slapd; \ chown "$SLAPD_USER":"$SLAPD_GROUP" /run/slapd; \ [ -d "$SLAPD_CONF" ] && confflag=-F || confflag=-f; \ exec /usr/sbin/slapd -d0 \ ${SLAPD_SERVICES:+-h "$SLAPD_SERVICES"} \ ${SLAPD_USER:+-u "$SLAPD_USER"} \ ${SLAPD_GROUP:+-g "$SLAPD_GROUP"} \ ${SLAPD_CONF:+$confflag "$SLAPD_CONF"} \ $SLAPD_OPTIONS' ERROR:systemctl: slapd.service: Exec command does not exist: (ExecStart) sh ERROR:systemctl: slapd.service: but this does exist: /usr/bin/sh ERROR:systemctl: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ERROR:systemctl: The SystemD ExecXY commands must always be absolute paths by definition. ERROR:systemctl: Oops, 1 executable paths were not found in the current environment. Refusing. ERROR:systemctl: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Regards, Dan Nisbet -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10488] New: Multiple out-of-bounds reads in servers/slapd/result.c v2ref() function
by openldap-its＠openldap.org 22 May '26

22 May '26

https://bugs.openldap.org/show_bug.cgi?id=10488 Issue ID: 10488 Summary: Multiple out-of-bounds reads in servers/slapd/result.c v2ref() function Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: wangxiaomeng(a)kylinos.cn Target Milestone: --- Created attachment 1142 --> https://bugs.openldap.org/attachment.cgi?id=1142&action=edit Fix two out-of-bounds reads in servers/slapd/result.c v2ref() function The v2ref() function in servers/slapd/result.c is responsible for converting LDAPv3 referrals to an LDAPv2-compatible string format. Two separate out-of-bounds read vulnerabilities exist in this function, both caused by insufficient checks for zero-length data before accessing the last character of the data buffer. Vulnerability 1: Out-of-bounds read in text buffer handling Location: servers/slapd/result.c, line 94 (within the v2ref() function): Vulnerable Code: if ( text != NULL ) { len = strlen( text ); if (text[len-1] != '\n') { i = 1; } } When the 'text' parameter is non-NULL but points to an empty string (""), strlen(text) returns 0. Accessing text[len-1] (i.e., text[-1]) results in an out-of-bounds read of one byte before the start of the 'text' buffer. Vulnerability 2: Out-of-bounds read in BerValue referral handling Location: servers/slapd/result.c, line 115 (within the v2ref() function) Vulnerable Code: len += ref[i].bv_len; if (ref[i].bv_val[ref[i].bv_len-1] != '/') { ++len; } When ref[i].bv_val is non-NULL but ref[i].bv_len is 0 (a valid state per LDAP BerValue semantics, representing an empty string), accessing ref[i].bv_val[ref[i].bv_len-1] (i.e., ref[i].bv_val[-1]) results in an out-of-bounds read of one byte before the start of the ref[i].bv_val buffer. Fix Add checks for zero-length data before accessing the last character of the respective buffers. The fix addresses both vulnerabilities with minimal, targeted changes that preserve the original functionality. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 10511] New: Add pagesize setting to back-mdb
by openldap-its＠openldap.org 20 May '26

20 May '26

https://bugs.openldap.org/show_bug.cgi?id=10511 Issue ID: 10511 Summary: Add pagesize setting to back-mdb Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- With LMDB 1.0, the DB pagesize is now configurable. Add an option to back-mdb to support this. Larger page sizes accommodate larger keys, which is also helpful when using multival. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10510] New: write_coherence can assert() on unbind
by openldap-its＠openldap.org 20 May '26

20 May '26

https://bugs.openldap.org/show_bug.cgi?id=10510 Issue ID: 10510 Summary: write_coherence can assert() on unbind Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- If lloadd links a client with a backend and that client issues a write and unbind in quick succession, the self-checks in client_reset are overly strict, triggering an assert. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs