openldap-bugs September 2026

openldap-bugs@openldap.org

1 participants
70 discussions

[Issue 10599] New: Compile error on Suse and older GCCs
by openldap-its＠openldap.org 22 Sep '26

22 Sep '26

https://bugs.openldap.org/show_bug.cgi?id=10599 Issue ID: 10599 Summary: Compile error on Suse and older GCCs Product: OpenLDAP Version: 2.7.0 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: dstoychev(a)symas.com Target Milestone: --- Created attachment 1213 --> https://bugs.openldap.org/attachment.cgi?id=1213&action=edit Diff of an example solution When building OpenLDAP on openSUSE 15.6 (which uses gcc 7) I get these errors: ``` tls_o.c: In function ‘tlso_ctx_init’: tls_o.c:547:7: error: a label can only be part of a statement and a declaration is not a statement X509 *cert = OSSL_STORE_INFO_get0_CERT( info ); ^~~~ tls_o.c:548:7: error: expected expression before ‘X509_STORE’ X509_STORE *store = SSL_CTX_get_cert_store( ctx ); ^~~~~~~~~~ tls_o.c:549:34: error: ‘store’ undeclared (first use in this function) if ( !X509_STORE_add_cert( store, cert ) ) { ^~~~~ tls_o.c:549:34: note: each undeclared identifier is reported only once for each function it appears in tls_o.c:757:6: error: a label can only be part of a statement and a declaration is not a statement X509 *cert = OSSL_STORE_INFO_get0_CERT(info); ^~~~ tls_o.c:758:6: error: expected expression before ‘int’ int is_ca = X509_check_ca( cert ); ^~~ tls_o.c:759:12: error: ‘is_ca’ undeclared (first use in this function); did you mean ‘ns_c_2’? if ( !is_ca && !SSL_CTX_use_certificate( ctx, cert )) { ^~~~~ ns_c_2 tls_o.c:777:6: error: a label can only be part of a statement and a declaration is not a statement X509_STORE *x509_s = SSL_CTX_get_cert_store( ctx ); ^~~~~~~~~~ ``` It does not happen on newer GCCs. This appears to be because on older GCC it is not allowed to have variable assignment right after a label and in tls_o.c there are `case` labels followed by a variable assignment (X509 *cert = OSSL_STO...) . One way to fix this is by putting the body of the case inside curly braces {}. Attaching an example diff that works to fix the issue for me. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10596] New: back-ldap: tainting of a cached connection doesn't remove it from cache
by openldap-its＠openldap.org 22 Sep '26

22 Sep '26

https://bugs.openldap.org/show_bug.cgi?id=10596 Issue ID: 10596 Summary: back-ldap: tainting of a cached connection doesn't remove it from cache Product: OpenLDAP Version: 2.6.14 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- The patch for ITS#10550 was incomplete and missed the removal when only tainting. This eventually leaves a freed connection in the tree. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10589] New: multiple issues with ppolicy rules and rehash in ppolicy
by openldap-its＠openldap.org 22 Sep '26

22 Sep '26

https://bugs.openldap.org/show_bug.cgi?id=10589 Issue ID: 10589 Summary: multiple issues with ppolicy rules and rehash in ppolicy Product: OpenLDAP Version: 2.7.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: david.coutadeur(a)gmail.com Target Milestone: --- Created attachment 1202 --> https://bugs.openldap.org/attachment.cgi?id=1202&action=edit OpenLDAP Configuration Hello, I have tested recently the new ppolicy features of OpenLDAP 2.7.1. Thanks for this great work! The new features sound really exciting. Nevertheless, I have encountered some issues during testing. As these are new features, I don't know if this is a misconfiguration problem coming from me, or if there are bugs. You can find attached the configuration and data I have used. 1. I noticed that pwdPolicySubentry as static attribute is now deprecated. How could we assign directly a specific policy to a user in the future? 2. Using olcPPolicyRuleGroupAttr attribute in a scope rule generates a coredump while OpenLDAP tries to evaluate the assigned ppolicy. (ie during user entry loading). See the configuration. 3. I tried to configure a regex rule for assigning password policies. OpenLDAP crashes when trying to compute the assigned ppolicy. (when searching a user entry matching the policy). Maybe I have not correctly defined the regex rule, but I found no concrete example of this in documentation or unit tests. 4. Trying to run OpenLDAP in debug mode with TRACE level. (-d -1), whith given configuration and data makes OpenLDAP crash at startup, with no special log. It is due to scope and regex rules, as when I remove them, OpenLDAP starts normally. 5. For pwdRehashOnBind feature, I didn't understand the "If pwdReset is set to "TRUE"" part in the man page. The current behaviour I observed is that when pwdReset is TRUE, the password is never rehashed. What is the intent here? 6. When I try to modify a password from a user having a directly assigned ppolicy (pwdPolicySubentry defined statically), the password is never rehashed. Thanks in advance for your help! -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10591] New: slapo-syncprov frees modtarget and sessionlog nodes without checking that they were removed from their AVL tree, causing a use-after-free and SIGSEGV in the comparison callback
by openldap-its＠openldap.org 21 Sep '26

21 Sep '26

https://bugs.openldap.org/show_bug.cgi?id=10591 Issue ID: 10591 Summary: slapo-syncprov frees modtarget and sessionlog nodes without checking that they were removed from their AVL tree, causing a use-after-free and SIGSEGV in the comparison callback Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: bohdan.kmit(a)kiteworks.com Target Milestone: --- ## Symptom slapd terminates with SIGSEGV. Across 89 coredumps collected from several instances, 64 abort inside `malloc()` and 18 inside `free()` at unrelated allocation sites — glibc detecting an already-corrupt heap at whatever the process allocated next, reported variously as: ``` double free or corruption (out) malloc(): unaligned tcache chunk detected malloc(): unaligned fastbin chunk detected ``` Two cores caught the fault itself rather than a later detection. Both have no allocator frame and are structurally identical: ``` #0 sp_avl_cmp (c1=0x7f5778104590, c2=0x7f5f4954e13a) at syncprov.c:433 #1 ldap_avl_delete (root=..., data=c1, fcmp=sp_avl_cmp) at avl.c:199 #2 syncprov_op_cleanup (op, rs) at syncprov.c:1589 #3 slap_cleanup_play at result.c:607 #4 send_ldap_response at result.c:797 #5 slap_send_ldap_result at result.c:926 #6 mdb_add at add.c:389 #7 overlay_op_walk (which=op_add) at backover.c:706 #9 accesslog_response at accesslog.c:1966 #10 slap_response_play at result.c:573 #13 mdb_modify at modify.c:803 #16 syncrepl_message_to_op at syncrepl.c:3271 #17 do_syncrep2 at syncrepl.c:1555 #18 do_syncrepl at syncrepl.c:2197 ``` `si_addr` is `c2 + 0x10` in both. `modtarget` is ```c typedef struct modtarget { struct modinst *mt_mods; /* +0 */ struct modinst *mt_tail; /* +8 */ struct berval mt_dn; /* +16 -> bv_len */ ldap_pvt_thread_mutex_t mt_mutex; } modtarget; ``` so offset 16 is `mt_dn.bv_len`, exactly the field `sp_avl_cmp` reads at syncprov.c:433. Both `c2` values are not 8-byte aligned, so `si_mods` is holding freed and reused memory rather than a live `modtarget`. The path is a replicated MODIFY applied by syncrepl, whose response triggers the accesslog overlay to perform a nested internal ADD into the log database; that nested operation's cleanup walks `si_mods` and dereferences the stale node. ## Analysis `syncprov_op_cleanup()`, syncprov.c: ```c ldap_avl_delete( &si->si_mods, mt, sp_avl_cmp ); /* return value ignored */ ldap_pvt_thread_mutex_unlock( &si->si_mods_mutex ); ldap_pvt_thread_mutex_destroy( &mt->mt_mutex ); ch_free( mt->mt_dn.bv_val ); ch_free( mt ); ``` `ldap_avl_delete()` returns the node it removed, or NULL when the comparison does not locate it. Since `sp_avl_cmp` orders by `mt_dn`, a search can fail to find a target that is physically still in the tree, and can also match a different target that shares a DN. In either case `mt` is freed while still linked, and the next traversal dereferences it. Access to the tree is correctly serialised at all three sites (`ldap_avl_find` at :2787, `ldap_avl_insert` at :2861, `ldap_avl_delete` at :1589 all under `si_mods_mutex`), so this is a lifetime defect rather than a data race. Three related weaknesses in the same overlay: 1. `ldap_avl_insert()` at syncprov.c:2861 also ignores its return. A failed insert leaves `mt` unreferenced by the tree while `opc->smt` still points at it, so the later cleanup finds nothing to remove. 2. The `mt_mods` walk at syncprov.c:1574 and the `mt_mods` and `o_callback` walks in the abandon path at syncprov.c:2848 and :2856 have no termination condition: ```c for (m2 = &mt->mt_mods; ; m2 = &(*m2)->mi_next) { ``` If the entry is not on the list the loop runs off the end. This is the same pattern ITS#10408 corrected for `si_ops`, which was released in 2.6.15; the equivalent code two functions away was not changed. 3. The sessionlog trim at syncprov.c:1799 has the identical delete-then-free shape on a different tree: ```c ldap_tavl_delete( &sl->sl_entries, se, syncprov_sessionlog_cmp ); ch_free( se ); ``` One of the collected cores aborts in `syncprov_add_slog()` -> `ldap_tavl_insert()` at syncprov.c:1754, consistent with that tree also holding a freed node. The sessionlog is written on every logged operation, so on a busy provider it is exercised harder than `si_mods`. ## Same defect in two other overlays Found while auditing for the pattern; neither was loaded when the crash was observed, so these are reported from code inspection only. `slapo-pcache`, `remove_from_template()`: `ldap_avl_delete()` on `template->qbase` is unchecked and followed immediately by `ch_free( qc->qbase )`. The `ldap_tavl_delete()` on the scope tree above it is also unchecked, and both callers free `qc` only later, so a failed removal leaves either tree pointing at freed memory. `slapo-seqmod`, `seqmod_op_cleanup()`: the lookup result is validated with `assert( av != NULL )` and then dereferenced as `av->avl_data`. Under NDEBUG the assert is compiled out and the dereference faults instead. Its `ldap_avl_delete()` is also unchecked, though nothing is freed on that path. An audit of `servers/slapd` found no other unguarded `for (p = &head; ; p = &(*p)->next)` list walks, and `back-ldap/chain.c:1506` already checks its `ldap_tavl_delete()` return and logs on failure. ## Affected versions Verified byte-identical in `OPENLDAP_REL_ENG_2_6_15`, `OPENLDAP_REL_ENG_2_7_0`, `OPENLDAP_REL_ENG_2_7_1` and current `master`. Diffing `syncprov.c` between 2.6.15 and master produces no hunk touching `si_mods`, `modtarget`, `sp_avl_cmp`, `mt_mods`, `mt_tail` or `opc->smt`, and `avl.c` is unchanged. So there is no release to upgrade to. Crash observed on 2.6.15, x86-64, glibc, back-mdb, overlays `syncprov` and `accesslog` loaded, three-way multi-provider mesh with delta-syncrepl consumers reading the accesslog. Sustained write load of roughly 25 to 30 operations per second. ## Proposed fix Three patches, one per overlay: 1. **slapo-syncprov** — capture the return of `ldap_avl_delete()` and `ldap_tavl_delete()` and free only on an identity match, logging otherwise; bound the three list walks; report a failed `ldap_avl_insert()`. This converts a use-after-free into a bounded leak: a leaked `modtarget` is a few dozen bytes plus a DN, a dangling one takes the process down. 2. **slapo-pcache** — same guard on both removals in `remove_from_template()`. 3. **slapo-seqmod** — replace the assert with a real check that releases the mutex, completes the callback teardown and returns; report a failed `ldap_avl_delete()`. -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 10528] New: core.ldif fails to load via "include:" in cn=config on Symas OpenLDAP 2.6.13-3 (RHEL 9)
by openldap-its＠openldap.org 18 Sep '26

18 Sep '26

https://bugs.openldap.org/show_bug.cgi?id=10528 Issue ID: 10528 Summary: core.ldif fails to load via "include:" in cn=config on Symas OpenLDAP 2.6.13-3 (RHEL 9) Product: OpenLDAP Version: 2.6.13 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: lucas.vicente(a)ebz.tec.br Target Milestone: --- Hello, We are experiencing an issue while trying to load the core.ldif schema default using the dynamic configuration (cn=config). When using the following in my LDIF: include: file:///opt/symas/etc/openldap/schema/core.ldif I get this error: olcAttributeTypes: value #48 olcAttributeTypes: Unexpected token before MUST c MAY ( searchGuide $ description ) ) slapadd: could not add entry dn="cn={0}core,cn=schema,cn=config" (line=14): olcAttributeTypes: Unexpected token before MUST c MAY ( searchGuide $ description ) ) Obs: If I create a slapd.conf that includes the core schema and run: slaptest -f slapd.conf -F /tmp/slapd.d It works without errors. However, when trying to load the same schema using slapadd + include: in cn=config, it fails. For reference, I tested the same steps on version 2.6.10 and it worked without errors. Steps to reproduce: Install Symas OpenLDAP 2.6.13 on RHEL 9 Try to load the core schema using: dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema include: file:///opt/symas/etc/openldap/schema/core.ldif Would you be able to verify this behavior? Thanks! -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10579] New: tlso_sb_{read,write} don't handle the opposite condition
by openldap-its＠openldap.org 18 Sep '26

18 Sep '26

https://bugs.openldap.org/show_bug.cgi?id=10579 Issue ID: 10579 Summary: tlso_sb_{read,write} don't handle the opposite condition Product: OpenLDAP Version: 2.7.0 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: --- With non-blocking BIO (lloadd), a SSL_write can error out with SSL_ERROR_WANT_READ and vice versa, e.g. at renegotiation or more points if TLS 1.3 is in place. Without knowing that, lloadd (or other applications if we ever say non-blocking OpenSSL use is supported) cannot make the right decisions, e.g. close a healthy connection. Of course lloadd also needs to expect this situation and arm the correct callback otherwise things get even worse. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10550] New: back ldap idletimeout broken
by openldap-its＠openldap.org 16 Sep '26

16 Sep '26

https://bugs.openldap.org/show_bug.cgi?id=10550 Issue ID: 10550 Summary: back ldap idletimeout broken Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- When an operation takes longer than idletimeout/conttl, back-ldap decides to terminate the connection. But if that connection is private, it doesn't do it right and asserts in ldap_back_conn_delete Two issues: - the TAINTED flag should not be set without the real state being set to match - a connection with an outstanding operation shouldn't be considered idle -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10590] New: sssvlv rejects multiple sort keys with protocolError in OpenLDAP 2.6.15
by openldap-its＠openldap.org 15 Sep '26

15 Sep '26

https://bugs.openldap.org/show_bug.cgi?id=10590 Issue ID: 10590 Summary: sssvlv rejects multiple sort keys with protocolError in OpenLDAP 2.6.15 Product: OpenLDAP Version: 2.6.15 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: christian(a)roessner.email Target Milestone: --- Created attachment 1204 --> https://bugs.openldap.org/attachment.cgi?id=1204&action=edit repro.go: anonymous RootDSE one-key versus two-key sorting (go-ldap v3.4.14) OpenLDAP 2.6.15 with the sssvlv overlay rejects a valid server-side sorting control containing two keys with: LDAP Result Code 2 "Protocol Error": serverSort control: decoding error A single key succeeds. Two keys fail with and without the simple paged results control. Reproduced using go-ldap/v3 v3.4.14, including an anonymous RootDSE base search. Tested pairs: cn + uid and uniqueIdentifier + uid, with caseIgnoreOrderingMatch explicitly selected for both keys. The application binds before requesting its initial sorted page, so this presents to users as a connection failure despite successful authentication. Environment: OpenLDAP 2.6.15 in a Linux x86_64 container (chrroessner/openldap LTS), on an AlmaLinux 10.2 host; client Go / macOS x86_64. The configuration loads sssvlv and enables overlay sssvlv. No sort-key limit override is configured (default five). A pristine upstream build has not yet been run for comparison. REPRODUCTION The attached repro.go sends only anonymous RootDSE searches, without reading directory accounts or writing data. Run against a disposable local server with sssvlv registered and a localhost LDAP listener on port 1389: mkdir ldap-sort-repro && cd ldap-sort-repro go mod init example.org/ldap-sort-repro go get github.com/go-ldap/ldap/v3@v3.4.14 # Copy the attached repro.go into this directory. go run . Expected: valid one-key and two-key requests are accepted. Observed on 2.6.15: the one-key case succeeds; both two-key cases return the diagnostic above. SUSPECTED CAUSE In servers/slapd/overlays/sssvlv.c, build_key(), comparison of upstream tags OPENLDAP_REL_ENG_2_6_13 and OPENLDAP_REL_ENG_2_6_15 shows the closing ber_scanf(ber, "}") replaced with: if (( tag = ber_peek_tag( ber, &len )) != LBER_DEFAULT ) { rs->sr_text = "serverSort control: decoding error"; rs->sr_err = LDAP_PROTOCOL_ERROR; return rs->sr_err; } The parser still shares the enclosing SortKeyList BER cursor across keys. After the first valid key, the next key's SEQUENCE remains in the cursor, so this check rejects a valid second key. This source change matches the observed diagnostic. The initial sequence handling also changed from ber_scanf to ber_skip_tag. The intended validation appears to require enforcing the boundary of the current SortKey SEQUENCE, while permitting the next key in SortKeyList. Simply accepting arbitrary trailing BER would not be an appropriate fix. Source: https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_6_15/s… Potentially related: ITS#10564, which records the sss_parseCtrl tightening (RE26 commit 6c0323aa). This report concerns rejection of valid sibling sort keys, not the malformed-input issue reported there. The release branch and current master source inspected on 2026-09-14 contain the same build_key() end-of-input check. This is source inspection, not a master runtime test. No live comparison against 2.6.13 was performed, so this report does not claim a verified first affected release. TEMPORARY CLIENT MITIGATION On the exact diagnostic above, retry only an initial search (no active paging cookie) with the primary sort key alone. Preserve that key for subsequent pages and cursor release. This drops the UID tie-breaker for equal primary values. Other errors remain visible. Suggested regression coverage: two and three keys, optional orderingRule/reverseOrder, paging continuation and cursor release, plus malformed/trailing BER rejection. -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 10455] New: Allow handling of empty group in memberof_saveMember_cb()
by openldap-its＠openldap.org 09 Sep '26

09 Sep '26

https://bugs.openldap.org/show_bug.cgi?id=10455 Issue ID: 10455 Summary: Allow handling of empty group in memberof_saveMember_cb() Product: OpenLDAP Version: 2.6.12 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: roger.j.meier(a)gmx.ch Target Milestone: --- Created attachment 1117 --> https://bugs.openldap.org/attachment.cgi?id=1117&action=edit Protect e_attrs with a NULL pointer test instead of an assert() to allow empty groups In slapd/overlays/memberof.c, the callback memberof_saveMember_cb() uses two assert statements for the sr_entry and its e_attrs pointer in sequence. This makes the service abort on an empty group. If the use of rs->sr_entry->e_attrs is just protected by a test of the e_attrs pointer, the code does not abort and allows empty groups. Please consider to add this patch to the official source. It was now several month in production and did not lead to unexpected results. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10566] A single unauthenticated LDAP request aborts the entire OpenLDAP slapd process
by openldap-its＠openldap.org 08 Sep '26

08 Sep '26

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

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2026