openldap-bugs

openldap-bugs@openldap.org

1 participants
21418 discussions

[Issue 10546] New: ldap_explode_dn result is not released in the interactive test client
by openldap-its＠openldap.org 20 Jul '26

20 Jul '26

https://bugs.openldap.org/show_bug.cgi?id=10546 Issue ID: 10546 Summary: ldap_explode_dn result is not released in the interactive test client Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: 1489378385(a)qq.com Target Milestone: --- URL: https://github.com/openldap/openldap/blob/8afcbe9e04f1a40f03cea51c57418b05f… Description: Source revision: 8afcbe9e04f1a40f03cea51c57418b05f86e8f44 Affected file: libraries/libldap/test.c Affected lines: 472-478 Source-level observation: The interactive test client's E command calls ldap_explode_dn() and stores the returned NULL-terminated array in exdn. It prints the array elements and then leaves the switch case without releasing exdn. According to ldap_get_dn(3), the result returned by ldap_explode_dn() should be released with ldap_value_free(). The only reference to the allocated array is overwritten the next time the E command is executed. Steps to verify: 1. Build the libraries/libldap interactive test client with AddressSanitizer or LeakSanitizer enabled. 2. Start the test client. 3. Execute the E command and enter a valid DN, for example: cn=test,dc=example,dc=com 4. Repeat the E command several times. 5. Exit the client and inspect the sanitizer report or monitor its memory use. Actual result: Each E command allocates an exploded DN array that remains allocated until the process terminates. Expected result: The exploded DN array should be released after all of its elements have been printed. Impact: Repeated use of the E command increases the test client's memory consumption. Validation status: Confirmed by source review at the revision above. Runtime sanitizer validation is pending. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10545] New: urltest leaks the parsed LDAPURLDesc and reconstructed URL string
by openldap-its＠openldap.org 20 Jul '26

20 Jul '26

https://bugs.openldap.org/show_bug.cgi?id=10545 Issue ID: 10545 Summary: urltest leaks the parsed LDAPURLDesc and reconstructed URL string Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: 1489378385(a)qq.com Target Milestone: --- URL: https://github.com/openldap/openldap/blob/8afcbe9e04f1a40f03cea51c57418b05f… Description: Source revision: 8afcbe9e04f1a40f03cea51c57418b05f86e8f44 Affected file: libraries/libldap/urltest.c Affected lines: 75 and 125-127 Source-level observation: On a successful call, ldap_url_parse() allocates an LDAPURLDesc and stores it in lud. The program reaches its final return without calling ldap_free_urldesc(lud). There is also a second allocation on line 125: fprintf(stdout, "URL: %s\n", ldap_url_desc2str(lud)); ldap_url_desc2str() allocates its returned string with LDAP_MALLOC. Because the return value is passed directly to fprintf(), its pointer is lost and the string cannot be released. Steps to verify: 1. Build libraries/libldap/urltest with AddressSanitizer or LeakSanitizer. 2. Run it with a valid URL, for example: ./urltest 'ldap://localhost/dc=example,dc=com??sub?(objectClass=*)' 3. Allow the program to exit successfully. 4. Inspect the sanitizer report. Actual result: A successful invocation exits without releasing either the LDAPURLDesc or the string returned by ldap_url_desc2str(). Expected result: Both allocations should be released before returning from main(). Impact: Each successful run leaves two process-lifetime allocations. The practical impact is low because urltest is a short-lived test utility, but the ownership contracts are not followed and leak detectors report the allocations. Validation status: Confirmed by source review at the revision above. Runtime sanitizer validation is pending. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10544] New: slapd-bind parses the -B search URL but neither uses nor frees it
by openldap-its＠openldap.org 20 Jul '26

20 Jul '26

https://bugs.openldap.org/show_bug.cgi?id=10544 Issue ID: 10544 Summary: slapd-bind parses the -B search URL but neither uses nor frees it 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: 1489378385(a)qq.com Target Milestone: --- URL: https://github.com/openldap/openldap/blob/8afcbe9e04f1a40f03cea51c57418b05f… Description: Source revision: 8afcbe9e04f1a40f03cea51c57418b05f86e8f44 Affected file: tests/progs/slapd-bind.c Affected lines: 98, 116-143, and 182-190 Source-level observation: When -B search=<LDAP URL> is supplied, ldap_url_parse() allocates an LDAPURLDesc and stores it in extra_ludp. After parsing, extra_ludp is not referenced again. In particular, the calls to do_base() and do_bind() pass an action type of -1 and an action pointer of NULL instead of passing TESTER_SEARCH and extra_ludp. The descriptor is also not released before exit(EXIT_SUCCESS). Steps to verify: 1. Build slapd-bind with AddressSanitizer or LeakSanitizer. 2. Run slapd-bind with the required connection arguments and a valid option such as: -B 'search=ldap:///dc=example,dc=com??sub?(objectClass=*)' 3. Allow the tester to complete normally. 4. Check whether the requested search action is performed. 5. Inspect the sanitizer report for the LDAPURLDesc allocated by ldap_url_parse(). Actual result: The URL is successfully parsed, but the resulting descriptor is neither used by the bind operation nor released before the process exits. Expected result: The parsed search action should be passed to the relevant test operation and the LDAPURLDesc should be released after the outer test loop completes. Impact: The -B search option appears to have no effect and leaves one LDAPURLDesc allocated until process termination. Validation status: Confirmed by source review at the revision above. Runtime behavior and sanitizer validation are pending. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10543] New: slapd-read frees the DN pointer array but not the ldap_get_dn() strings
by openldap-its＠openldap.org 20 Jul '26

20 Jul '26

https://bugs.openldap.org/show_bug.cgi?id=10543 Issue ID: 10543 Summary: slapd-read frees the DN pointer array but not the ldap_get_dn() strings 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: 1489378385(a)qq.com Target Milestone: --- URL: https://github.com/openldap/openldap/blob/8afcbe9e04f1a40f03cea51c57418b05f… Description: Source revision: 8afcbe9e04f1a40f03cea51c57418b05f86e8f44 Affected file: tests/progs/slapd-read.c Affected lines: 204-232 Source-level observation: do_random() allocates the values pointer array with malloc(). It then calls ldap_get_dn() once for every LDAP search result and stores each independently allocated DN string in values[i]. After the read loop, the code calls: free(values); This releases only the pointer array. It does not release any of the strings returned by ldap_get_dn(). The ldap_get_dn(3) documentation states that its returned string is dynamically allocated and should be released with ldap_memfree(). Steps to verify: 1. Build slapd-read with AddressSanitizer or LeakSanitizer. 2. Run it with a search filter so that do_random() is used. 3. Use a search base containing multiple matching entries. 4. Run multiple outer iterations if possible. 5. Allow the tester to exit and inspect the sanitizer report. Actual result: One DN string remains allocated for every entry returned by each search batch. Only the surrounding values array is freed. Expected result: Every non-NULL value returned by ldap_get_dn() should be released before the values array is freed. Impact: The leak scales with the number of matching entries and the number of outer test iterations. Long or repeated test runs can accumulate substantially more memory than the other three findings. Validation status: Confirmed by source review at the revision above. Runtime sanitizer validation is pending. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10542] New: On Windows, allow using previous write behavior
by openldap-its＠openldap.org 17 Jul '26

17 Jul '26

https://bugs.openldap.org/show_bug.cgi?id=10542 Issue ID: 10542 Summary: On Windows, allow using previous write behavior Product: LMDB Version: 1.0.0 Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- ITS#9017 changed write behavior in Windows to use WRITE_THROUGH writes and eliminate use of FlushFileBuffers(). Supposedly this yields faster write performance because flushes are very slow. However, other users report this approach is actually much slower than LMDB 0.9. Add a compile-time flag to revert to the original write behavior. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10541] New: syncrepl regression with older format of entryCSN
by openldap-its＠openldap.org 16 Jul '26

16 Jul '26

https://bugs.openldap.org/show_bug.cgi?id=10541 Issue ID: 10541 Summary: syncrepl regression with older format of entryCSN Product: OpenLDAP Version: 2.6.13 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: benp(a)reed.edu Target Milestone: --- We recently upgraded from openldap 2.6.10 to 2.6.13 (using debian packages from symas.com). Subsequent to the upgrade we noticed that syncrepl was sometimes failing to replicate changes to entries. It appears that the behavior is triggered when modifying an entry with an older style entryCSN (eg "entryCSN: 20210115230536Z#000001#00#000000" vs the current style "entryCSN: 20260715174316.844052Z#000000#001#000000"). The updated entry on the provider slapd gets a new entryCSN that uses the new format, but the consumer slapds don't process the changes made to the entry, and log a failed assertion (122) error like this: Jul 8 10:39:28 slapd-c daemon.info slapd[129831]: 6a3f4436.0d08671e 0x7f6d411fc6c0 syncrepl_entry: rid=011 be_modify uid=example-user,ou=People,dc=foo,dc=bar (122) Deleting the problematic entry on the provider and then recreating it tends to resolve the issue for us, presumably because the new entry has the normal non-obsolete contextCSN attribute. Our current production DB has ~22k entries, ~4k of which have older style contextCSNs, so we'd love to avoid having to delete and recreate those ~4k entries if we don't have to. We have entryCSNs in at least 3 different formats: entryCSN: 2003081423:11:31Z#0x000d#0#0000 entryCSN: 20230410142047Z#000000#00#000000 entryCSN: 20260313112653.221151Z#000000#001#000000 Our current configuration does not use accesslog, so replication is simple syncrepl (vs delta-syncrepl). It was suggested on the openldap-technical list that we consider filing an ITS about this issue. Please let me know what additional supporting information would be helpful. I'm not totally certain how to distill are slapd.d style config to something concise enough for the bug tracker. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10538] New: On Windows, a large value write can get silently lost
by openldap-its＠openldap.org 16 Jul '26

16 Jul '26

https://bugs.openldap.org/show_bug.cgi?id=10538 Issue ID: 10538 Summary: On Windows, a large value write can get silently lost Product: LMDB Version: 0.9.35 Hardware: x86_64 OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: github(a)nicwatson.org Target Milestone: --- On Windows, mdb_page_flush() writes each overflow page with a single WriteFile() whose write bytes is a 32-bit DWORD. A value whose overflow extent (psize * mp_pages) reaches 2**32 has its length truncated. An extent of exactly 2**32 truncates to 0, so WriteFile() writes nothing and the value is silently lost. The commit still "succeeds" (a 0-byte WriteFile returns TRUE), so the bug shows up as a value that reads back as zeroes instead of its contents. Here's a reproducer. This only works on Windows 64-bit. --- #include <stdio.h> #include <stdlib.h> #include <string.h> #include <direct.h> #define MKDIR(d) _mkdir(d) #include "lmdb.h" #define CHK(expr) do { int rc_ = (expr); if (rc_) { \ fprintf(stderr, "%s:%d: %s: %s\n", __FILE__, __LINE__, #expr, \ mdb_strerror(rc_)); return 2; } } while (0) int main(int argc, char **argv) { const char *dir = argc > 1 ? argv[1] : "lw-repro-db"; const size_t VALSIZE = (size_t)0xFFFFF000UL; MDB_env *env; MDB_txn *txn; MDB_dbi dbi; MDB_val key, val, got; unsigned char *p; char *buf; MKDIR(dir); buf = (char *)malloc(VALSIZE); if (!buf) { fprintf(stderr, "malloc(%zu) failed\n", VALSIZE); return 2; } memset(buf, 'x', VALSIZE); memcpy(buf, "HEAD", 4); memcpy(buf + VALSIZE - 4, "TAIL", 4); CHK(mdb_env_create(&env)); CHK(mdb_env_set_mapsize(env, VALSIZE + (256UL << 20))); CHK(mdb_env_open(env, dir, 0, 0664)); CHK(mdb_txn_begin(env, NULL, 0, &txn)); CHK(mdb_dbi_open(txn, NULL, 0, &dbi)); key.mv_data = (void *)"big"; key.mv_size = 3; val.mv_data = buf; val.mv_size = VALSIZE; CHK(mdb_put(txn, dbi, &key, &val, 0)); CHK(mdb_txn_commit(txn)); /* the overflow-page WriteFile happens here */ free(buf); CHK(mdb_txn_begin(env, NULL, MDB_RDONLY, &txn)); CHK(mdb_get(txn, dbi, &key, &got)); p = (unsigned char *)got.mv_data; if (got.mv_size != VALSIZE || memcmp(p, "HEAD", 4) != 0 || memcmp(p + VALSIZE - 4, "TAIL", 4) != 0) { fprintf(stderr, "BUG REPRODUCED: value truncated/lost: size=%zu " "head=%02x%02x%02x%02x tail=%02x%02x%02x%02x\n", got.mv_size, p[0], p[1], p[2], p[3], p[VALSIZE - 4], p[VALSIZE - 3], p[VALSIZE - 2], p[VALSIZE - 1]); mdb_txn_abort(txn); mdb_env_close(env); return 1; } mdb_txn_abort(txn); mdb_env_close(env); printf("OK: committed and read back %zu-byte value intact\n", VALSIZE); return 0; } -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10536] New: Re-fix ITS#8174 mdb_drop(MAIN_DBI)
by openldap-its＠openldap.org 16 Jul '26

16 Jul '26

https://bugs.openldap.org/show_bug.cgi?id=10536 Issue ID: 10536 Summary: Re-fix ITS#8174 mdb_drop(MAIN_DBI) Product: LMDB Version: 1.0.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- The patch breaks mdb_drop() usability. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

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

16 Jul '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 5

[Issue 10490] New: Bump library minor version(s)
by openldap-its＠openldap.org 14 Jul '26

14 Jul '26

https://bugs.openldap.org/show_bug.cgi?id=10490 Issue ID: 10490 Summary: Bump library minor version(s) 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: --- Tracking bug for 2.7 branchpoint if we expose new interfaces in either library. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

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