openldap-bugs

openldap-bugs@openldap.org

1 participants
21518 discussions

[Issue 10525] New: back-ldap accepts multiple tls_cert values in olcDbACLBind
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10525 Issue ID: 10525 Summary: back-ldap accepts multiple tls_cert values in olcDbACLBind Product: OpenLDAP Version: 2.6.13 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: --- In examining my slapd configuration, I found it had: olcDBACLBind: bindmethod=sasl sasl_mech=external tls_cert=/path/to/home/directory/cert tls_cert=/path/to/real/cert <rest of tls configuration> Fortunately it took the second value, so the connections worked, but I would expect this to generate an error -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10026] New: Refresh handling can skip entries (si_dirty not managed properly)
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10026 Issue ID: 10026 Summary: Refresh handling can skip entries (si_dirty not managed properly) Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Take MPR plain syncrepl with 3+ providers. When a provider's own syncrepl session transitions to persist and a it starts a new parallel session towards another host, that session always has to start as a refresh. If that refresh serves entries to us, our handling of si_dirty is not consistent: - if the existing persist session serves some of these entries to us, we can "forget" to pass the others to a newly connected consumer - same if the refresh is abandoned and we start refreshing from a different provider that might be behind what we were being served (again our consumers could suffer) - if we restart, si_dirty is forgotten and our consumers suffer even worse We might need to be told (at the beginning of the refresh?) what the end state we're going for is, so we can keep si_dirty on until then. And somehow persist that knowledge in the DB... -- You are receiving this mail because: You are on the CC list for the issue.

1 31

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

07 Aug '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 5

[Issue 8064] SIGSEGV in monitor-shutdown code
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=8064 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED Resolution|TEST |FIXED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10473] New: syncprov leaks response controls
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10473 Issue ID: 10473 Summary: syncprov leaks response controls Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- syncprov_state_ctrl and syncprov_done_ctrl add controls to the response, but noone cares to free them afterwards assuming they are allocated from the slab. If there are many messages sent in a single run, this takes up fresh memory that's leaked eventually. See its8800 regression test for an example where this happens. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

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

07 Aug '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 5

[Issue 10475] slapo-constraint URI mode fails to escape assertion values in internal catalog filters, enabling wildcard/filter-metachar allowlist bypass
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10475 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|TEST |FIXED Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10539] New: LMDB 1.0.0 fails to compile on Windows
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10539 Issue ID: 10539 Summary: LMDB 1.0.0 fails to compile on Windows 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: --- Various errors around use of LARGE_INTEGER -- You are receiving this mail because: You are on the CC list for the issue.

1 3

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

07 Aug '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 9

[Issue 10534] New: mdb_env_get_maxkeysize(): requires an _env_open()ed handle
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10534 Issue ID: 10534 Summary: mdb_env_get_maxkeysize(): requires an _env_open()ed handle Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: steffen(a)sdaoden.eu Target Milestone: --- Created attachment 1174 --> https://bugs.openldap.org/attachment.cgi?id=1174&action=edit git-enabled patch Super minor, but my LMDB implementation for the bogofilter program was buggy because of this. They had to fix it accordingly after almost 8 years, when updating to LMDB 1.0. Suggested fix would be something like - * @param[in] env An environment handle returned by #mdb_env_create() + * @param[in] env An environment handle that is #mdb_env_open() Thanks! And ciao. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

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