openldap-bugs January 2026

openldap-bugs@openldap.org

1 participants
26 discussions

[Issue 10428] New: Make larger key sizes available at compile time
by openldap-its＠openldap.org 22 Jan '26

22 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10428 Issue ID: 10428 Summary: Make larger key sizes available at compile time Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: marlowsd(a)gmail.com Target Milestone: --- I discovered that I can increase the key size to 1982 bytes with the following patch ``` *************** *** 1053,1059 **** #define METADATA(p) ((void *)((char *)(p) + PAGEHDRSZ)) /** ITS#7713, change PAGEBASE to handle 65536 byte pages */ ! #define PAGEBASE ((MDB_DEVEL) ? PAGEHDRSZ : 0) /** Number of nodes on a page */ #define NUMKEYS(p) ((MP_LOWER(p) - (PAGEHDRSZ-PAGEBASE)) >> 1) --- 1054,1061 ---- #define METADATA(p) ((void *)((char *)(p) + PAGEHDRSZ)) /** ITS#7713, change PAGEBASE to handle 65536 byte pages */ ! #define PAGEBASE PAGEHDRSZ ! // #define PAGEBASE ((MDB_DEVEL) ? PAGEHDRSZ : 0) /** Number of nodes on a page */ #define NUMKEYS(p) ((MP_LOWER(p) - (PAGEHDRSZ-PAGEBASE)) >> 1) ``` and then passing `-DMDB_MAXKEYSIZE=0` at compile time. I didn't want to use `MDB_DEVEL` because this is for a production use case. Is this feature ready to be widely used? If so, could it be given a compile-time (or run-time) flag please? Background: this is for Glean (https://github.com/facebookincubator/Glean/pull/663), this page explains our DB structure https://glean.software/docs/implementation/db/. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10427] New: ldapsearch(1) incorrectly documents OID-based search option
by openldap-its＠openldap.org 20 Jan '26

20 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10427 Issue ID: 10427 Summary: ldapsearch(1) incorrectly documents OID-based search option Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: michael.osipov(a)innomotics.com Target Milestone: --- Created attachment 1109 --> https://bugs.openldap.org/attachment.cgi?id=1109&action=edit Git-formatted patch Docs/manpage for -E say: [!]<oid>[=:<value>|::<b64value>] But it does not work: > $ ldapsearch -Y GSSAPI -O maxssf=1 -E '!1.2.840.113556.1.4.1340::MAYSBAAAAAI=' -o ldif-wrap=no -H ldap://innomotics.net "(objectClass=dnsNode1)" Invalid search extension name: 1.2.840.113556.1.4.1340::MAYSBAAAAAI It is '=::': > $ ldapsearch -Y GSSAPI -O maxssf=1 -E '!1.2.840.113556.1.4.1340=::MAYSBAAAAAI=' -o ldif-wrap=no -H ldap://innomotics.net "(objectClass=dnsNode1)" > SASL/GSSAPI authentication started Attached is a simple patch to fix it. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10426] New: liblber: ber_get_stringbvl integer overflow enables heap buffer overflow via {M} parsing (32-bit builds)
by openldap-its＠openldap.org 20 Jan '26

20 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10426 Issue ID: 10426 Summary: liblber: ber_get_stringbvl integer overflow enables heap buffer overflow via {M} parsing (32-bit builds) Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: lukas(a)artiphishell.com Target Milestone: --- Created attachment 1105 --> https://bugs.openldap.org/attachment.cgi?id=1105&action=edit build.sh ## Issue description Vulnerable location: `libraries/liblber/decode.c` in `ber_get_stringbvl()` Root cause: in the first pass that counts elements, `tot_size += siz` is performed with `ber_len_t` and no overflow check. On 32-bit builds, a large BER sequence (e.g., SearchRequest attributes parsed via `{M}`) wraps `tot_size`. The allocation uses the wrapped value (`ber_memalloc_x(tot_size + siz, ...)`), producing an undersized buffer. The second pass then writes `i` elements into the vector (BvOff mode for `{M}`), advancing `tot_size` by `siz` and storing `struct berval` at `res.bo + tot_size`, which overruns the allocation. Call path observed in the ASAN trace: `slapd` -> `do_search` (`servers/slapd/search.c:145`, `ber_scanf("{M}}")`) -> `ber_scanf` (`libraries/liblber/decode.c:815`) -> `ber_get_stringbvl` (`libraries/liblber/decode.c:471`) -> heap buffer overflow. ## Reproduction Steps Build instructions: ```bash mkdir /tmp/openldap-ber-get-stringbvl-overflow cd /tmp/openldap-ber-get-stringbvl-overflow # create the following files in this directory chmod +x build.sh poc.sh git clone https://github.com/openldap/openldap ./build.sh ./openldap # Run the PoC ./poc.sh ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10403] New: Add a configuration directive that uses the OpenSSL CONF API to allow openldap config files to set any configuration supported by that API, and to get new OpenSSL configuration capabilities through that API with no changes in openldap.
by openldap-its＠openldap.org 15 Jan '26

15 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10403 Issue ID: 10403 Summary: Add a configuration directive that uses the OpenSSL CONF API to allow openldap config files to set any configuration supported by that API, and to get new OpenSSL configuration capabilities through that API with no changes in openldap. Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: stephen.wall(a)redcom.com Target Milestone: --- Created attachment 1090 --> https://bugs.openldap.org/attachment.cgi?id=1090&action=edit Add a configuration directive that uses the OpenSSL CONF API to allow openldap config files to set any configuration supported by that API, and to get new OpenSSL configuration capabilities through th I am submitting a patch to create a new directive for OpenLDAP config files that uses the OpenSSL SSL_CONF API to allow configuration of any aspect of OpenSSL that the API supports without adding specific directives to OpenLDAP for them. When OpenSSL extends that API, all versions of OpenLDAP with thie patch will also support those extensions with no additional code. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10421] New: mdb_load can crash on malicious input
by openldap-its＠openldap.org 15 Jan '26

15 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10421 Issue ID: 10421 Summary: mdb_load can crash on malicious input Product: LMDB Version: 0.9.14 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: minor Priority: --- Component: tools Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- This is being reported as a DOS vulnerability, which is incorrect. https://www.socdefenders.ai/item/01d72f7a-9622-4384-a936-d99925a19a8f mdb_load is a command-line tool, not a server nor a library function that could be run in a server. There is no service to deny. Reading a line containing an embedded NUL byte may cause mdb_load to crash, but as it's a one-shot commandline tool such crashes have no consequences. The report claims "heap metadata leak" which is also irrelevant since this is a one-shot tool and the only potential metadata is that which was contained in the input file, whose contents are already known to the attacker. The report is supposedly released under "responsible disclosure" and yet it was never reported directly to the OpenLDAP Project (not in this bug tracker nor anywhere else). This despite the fact that the reporter clearly knows that mdb_load is a piece of OpenLDAP software. https://seclists.org/fulldisclosure/2026/Jan/5 The malicious input file must be constructed with a valid header and a line containing a single space followed by a single NUL byte. The dump/load file format only uses printable characters, so an embedded NUL byte never occurs in valid files. It is unclear why any DB admin would ever fall victim to such a malicious input. The mdb_load utility is only used to load files generated by mdb_dump, and mdb_dump will never produce such an invalid file. If an attacker went to the trouble to binary patch a dump file to create this crashing character sequence, they clearly have enough privileges to read and alter any other relevant files, so this crash doesn't give them any particular advantage. Nor does the crash reveal any memory content that they don't already know. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10395] New: Support multiple readers on uncommitted changes
by openldap-its＠openldap.org 14 Jan '26

14 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10395 Issue ID: 10395 Summary: Support multiple readers on uncommitted changes Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: renault.cle(a)gmail.com Target Milestone: --- Created attachment 1086 --> https://bugs.openldap.org/attachment.cgi?id=1086&action=edit A patch to support multiple readers on uncommitted changes Hello, The attached patch is not meant to be merged immediately into LMDB. Still, it demonstrates how I added a helpful feature to the key-value store: reading uncommitted changes from multiple transactions. I am conscious that the patch still requires some work and uses non-C99 features, i.e., atomics are C11, which could be a blocker for it to be merged upstream. I would also be delighted to merge these changes under a flag/define to ensure we don't impact other users with non-C99 stuff. The main feature we need at Meilisearch is to read uncommitted changes from multiple threads, compute parallel post-processing of different data structures [1], and speed up the search requests. We could have done the post-processing in a following transaction by opening multiple read transactions, but this would mean that the post-processed data structure would not include newly inserted or modified document IDs. Both data structures would be desync. Regarding the design choice, I decided to follow the same design as the nested write transactions: use the parent argument of the mdb_txn_begin [2], and allow the MDB_RDONLY flag, which was disallowed when the parent argument was non-NULL [3]. I find it clear enough that, by calling the mdb_txn_begin function with these arguments, you can call it multiple times (I need to update the doc) to obtain nested read-only transactions from the parent write transaction. ret = mdb_txn_begin(env, parent_txn, MDB_RDONLY, new_nested_rtxn); Note that this early proposal lacks security and error handling. The generated transactions are fake-read-only and actually write transactions that share the underlying parent allocations and data structures. This is unsafe and must be changed or reviewed carefully, but most importantly, we need to add read-only capabilities to these transactions to disallow writes. Using a Rust wrapper on top of LMDB, I wrapped the fake read-only transactions into ReadTxn, which disallows any writes at compile time. However, I haven't checked the conflict database creations or openings. The main issues I encountered were concurrent free of the main shared data structures when the different threads owning the transactions were dropping the transactions simultaneously. So, I decided to implement the equivalent of an ARC to free resources only when the last nested transaction was freed. I can share numbers about how this feature improves the post-processing by 4x-9x or from 1200s to 120s [1]. You can look at this PR, which I would be happy to merge once an improved version of this patch lands on LMDB upstream. I would be very happy if you could guide me a bit on how I could improve this patch to make it mergeable into LMDB. We want to contribute useful features like this to LMDB and not keep a deviant fork. LMDB works great; we are happy about it, and its performance is predictable. Have a lovely week, kero [1]: https://github.com/meilisearch/meilisearch/pull/5307 [2]: https://github.com/LMDB/lmdb/blob/14d6629bc8a9fe40d8a6bee1bf71c45afe7576b6/… [3]: https://github.com/LMDB/lmdb/blob/14d6629bc8a9fe40d8a6bee1bf71c45afe7576b6/… -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 10420] New: Add support for building on Haiku
by openldap-its＠openldap.org 13 Jan '26

13 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10420 Issue ID: 10420 Summary: Add support for building on Haiku Product: LMDB Version: unspecified Hardware: All OS: Other Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: alizter(a)gmail.com Target Milestone: --- The following patch allows for lmdb to be built on Haiku: ``` diff --git a/vendor/ocaml-lmdb/mdb.c b/vendor/ocaml-lmdb/mdb.c index 64e5ffd254..ffd8618ffa 100644 --- a/vendor/ocaml-lmdb/mdb.c +++ b/vendor/ocaml-lmdb/mdb.c @@ -174,6 +174,9 @@ # endif #elif defined(__ANDROID__) # define MDB_FDATASYNC fsync +#elif defined(__HAIKU__) +# define MDB_USE_POSIX_SEM 1 +# define MDB_FDATASYNC fsync #endif ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10419] New: NetBSD does not define union semun nor set _SEM_SEMUN_UNDEFINED
by openldap-its＠openldap.org 13 Jan '26

13 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10419 Issue ID: 10419 Summary: NetBSD does not define union semun nor set _SEM_SEMUN_UNDEFINED Product: LMDB Version: unspecified Hardware: All OS: Other Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: alizter(a)gmail.com Target Milestone: --- NetBSD does not define union semun nor set _SEM_SEMUN_UNDEFINED. This means that the union defined when _SEM_SEMUN_UNDEFINED is set is skipped leading to a compilation error. Adding this to `mdb.c` will fix this issue by setting this variable in NetBSD when it is undefined (and it usually is, I can't speak for the future). ``` diff --git a/mdb.c b/mdb.c index 3e3f529b98..64e5ffd254 100644 --- a/vendor/ocaml-lmdb/mdb.c +++ b/vendor/ocaml-lmdb/mdb.c @@ -176,6 +176,11 @@ # define MDB_FDATASYNC fsync #endif +/* NetBSD does not define union semun in sys/sem.h */ +#if defined(__NetBSD__) && !defined(_SEM_SEMUN_UNDEFINED) +# define _SEM_SEMUN_UNDEFINED 1 +#endif + #ifndef _WIN32 #include <pthread.h> #include <signal.h> ``` FreeBSD and OpenBSD don't suffer from this issue as they both correctly set that variable. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10424] New: When using more than one syncrepl directive on a single DB, the contextCSN should be stored accordingly to the replication base
by openldap-its＠openldap.org 13 Jan '26

13 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10424 Issue ID: 10424 Summary: When using more than one syncrepl directive on a single DB, the contextCSN should be stored accordingly to the replication base Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: elecharny(a)apache.org Target Milestone: --- Trying to replicate cn=config but parially, I tried to set many syncrepl directives so that each oe of them just replicate the single element it is configured for. Here is an exemple thet replicate the frontend database and only it: {0}rid=004 provider=ldaps://openldap1:10636 bindmethod=simple binddn="cn=syncrepl,ou=accounts,dc=worteks,dc=com" credentials=blah tls_cacert=/opt/application/openldap/ssl/ca.crt tls_cert=/opt/application/openldap/ssl/openldap-common.crt tls_key=/opt/application/openldap/ssl/openldap-common.key tls_reqcert=demand tls_protocol_min=3.3 searchbase="olcDatabase={-1}frontend,cn=config" scope="base" type=refreshAndPersist retry="30 +" timeout=1 schemachecking=off If I have this single syncrepl directive, all is ok, it replicates the frontend data and only this entry. Would I like to replicate, says, 'cn=config' with another syncrepl directive like: olcSyncrepl: {0}rid=001 provider=ldaps://openldap1:10636 bindmethod=simple binddn="cn=syncrepl,ou=accounts,dc=worteks,dc=com" credentials=blah tls_cacert=/opt/application/openldap/ssl/ca.crt tls_cert=/opt/application/openldap/ssl/openldap-common.crt tls_key=/opt/application/openldap/ssl/openldap-common.key tls_reqcert=demand tls_protocol_min=3.3 searchbase="cn=config" scope="base" type=refreshAndPersist retry="30 +" timeout=1 schemachecking=off where the search base is different, then suddenly I get some 'CSN too old' errors, which make totally sense as we only have one single contextCSN stored in the root entry (cn=config in my use case). I know I'm really border line here (and the rational is that I want a partial replication of cn=config because the two servers are a bit different), but I would suggest that the contextCSN to be stored in the entry associated to the searchBase, not at the root of the database. -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 10423] New: It is possible via cn=config to add an entry of one database type with the object class of another, causing OpenLDAP to crash
by openldap-its＠openldap.org 13 Jan '26

13 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10423 Issue ID: 10423 Summary: It is possible via cn=config to add an entry of one database type with the object class of another, causing OpenLDAP to crash Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- This happens specifically because the user by mistake attempts to create a meta database by specifying the object class for back-ldap. Since these share a lot of common attributes, schema checks do not fail. As a result, slapd initializes a meta database (based on olcDatabase value), but attempts to manipulate an initialized back-ldap database after that, and segfaults. Like this: dn: olcDatabase=meta,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: meta olcDbURI: "ldap://example.com" While it seems this is only possible for the proxy databases, we cannot rely that schema checks on attributes will fail for other database combinations, who knows what common attributes can be added or supplied in the future, we we have to fix this. The issue is reproducible via slapadd and at runtime with ldapadd. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2026