openldap-bugs June 2026

openldap-bugs@openldap.org

1 participants
209 discussions

[Issue 10437] New: Let service manager know when we're about to pause
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10437 Issue ID: 10437 Summary: Let service manager know when we're about to pause Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Entering a pause and waiting for a task (back-ldap result, ...) to finish looks exactly the same as slapd hanging, even cn=monitor will stop responding. If the sysadmin has systemd or another manager that we can tell this is about to happen, we might as well try. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10436] New: Assorted fixes for 2.7
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10436 Issue ID: 10436 Summary: Assorted fixes for 2.7 Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Minor cleanups for unitialised variables, typos and annoying compiler warnings. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10500] New: back-ldif/ldif.c crc32() should be static — collides with zlib's crc32 at link time
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10500 Issue ID: 10500 Summary: back-ldif/ldif.c crc32() should be static — collides with zlib's crc32 at link time Product: OpenLDAP Version: 2.6.13 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: ionutn(a)gmail.com Target Milestone: --- In servers/slapd/back-ldif/ldif.c, the helper crc32() (defined at line 393 in 2.6.13) is declared with external linkage: unsigned int crc32(const void *vbuf, int len) { ... } It is only used inside that file (lines 470 and 511). It has the same name as zlib's public crc32() but a completely different signature and semantics — it's an internal helper for hashing LDIF entry filenames, unrelated to zlib's CRC-32-IEEE-802.3. This is a latent symbol collision that has been present for many years. Until recently, ld silently resolved zlib's crc32 references (from inflate.c.o / deflate.c.o, transitively pulled in by libcrypto) against back-ldif's crc32 — because back-ldif is linked first — and libz.a's crc32.c.o was never pulled in. NEWLY EXPOSED BY zlib 1.3.2: zlib 1.3.2's deflate.c added an internal call to crc32_z, a symbol defined only in libz.a(crc32.c.o). When slapd is linked against libssl/libcrypto + libz.a, ld now has to pull in crc32.c.o to satisfy crc32_z, which brings the public crc32 along — colliding with back-ldif's: libz.a(crc32.c.o): In function `crc32': zlib-1.3.2/crc32.c:950: multiple definition of `crc32' libbackends.a(ldifldif.o):.../back-ldif/ldif.c:399: first defined here collect2: error: ld returned 1 exit status Reproduction: any build that links slapd (or anything pulling in libbackends.a) together with libssl + libcrypto + zlib 1.3.2's libz.a. Hit on Linux/aarch64 and Linux/x86_64 with GCC 8.5 + ld from binutils. Suggested fix (one keyword) --------------------------- Mark the function static: -unsigned int +static unsigned int crc32(const void *vbuf, int len) Tested locally on 2.6.13: slapd builds cleanly against zlib 1.3.2 with this change. No behaviour change since the function is only ever called from within ldif.c. Versions -------- - Confirmed: 2.6.13 (latest) and 2.6.10. The code path appears identical going back many releases. - ld behaviour change is triggered specifically by zlib 1.3.2 (released Feb 2026). -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[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 07 Aug '26

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

[Issue 10491] New: constraint_attribute <attrs...> count doesn't work with multiple attributes
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10491 Issue ID: 10491 Summary: constraint_attribute <attrs...> count doesn't work with multiple attributes 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: --- constraint_check_count_violation (run on Modifies/Renames) only really checks the last attribute in the list. Fix is coming. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10492] New: slapd: send_ldap_result must massage return code before handling abandon
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10492 Issue ID: 10492 Summary: slapd: send_ldap_result must massage return code before handling abandon 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: hyc(a)openldap.org Target Milestone: --- send_ldap_result checks if rs->sr_err == LDAP_REFERRAL and rs->sr_ref == NULL. In that case, there's no actual referral to send so it changes rs->sr_err to LDAP_NO_SUCH_OBJECT. Later send_ldap_response checks if rs->sr_ref == NULL and asserts if rs->sr_err == LDAP_REFERRAL. If an op was abandoned, the adjustment in send_ldap_result was being skipped, allowing the assert in send_ldap_response to get triggered. The fix is to move the check for abandon to after the error code adjustment has occurred. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10485] New: potential division by zero in tier bestof
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10485 Issue ID: 10485 Summary: potential division by zero in tier bestof 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: --- In rare cases gettimeofday could fall on tv_usec == 0 so we will just accept it's been exactly 1 second and go with that. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10482] New: Accesslog leaks UUID buffer when operation not logged
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10482 Issue ID: 10482 Summary: Accesslog leaks UUID buffer when operation not logged 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: --- Fix incoming -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10483] New: slapo-chain leaks structures added online
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10483 Issue ID: 10483 Summary: slapo-chain leaks structures added online 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: --- chain_ldadd stores the DB in ce->ce_be, but there is no teardown of these on shutdown so they get leaked and no way for ldap_chain_db_destroy to reach them either. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10481] New: cn=config leaks data in error path
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10481 Issue ID: 10481 Summary: cn=config leaks data in error path 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: --- Attempting an Add when objectclass is not known leaks in-progress structures. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

← Newer
1
...
10
11
12
13
14
15
16
...
21
Older →

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 June 2026