openldap-bugs

openldap-bugs@openldap.org

1 participants
21509 discussions

[Issue 10348] New: Free ch_malloc-allocated memory in error paths
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10348 Issue ID: 10348 Summary: Free ch_malloc-allocated memory in error paths Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: alexguo1023(a)gmail.com Target Milestone: --- Created attachment 1077 --> https://bugs.openldap.org/attachment.cgi?id=1077&action=edit Patch: Relase memory allocated from ch_malloc in 2 error handling branches. In ldap_back_monitor_ops_init and syncrepl_dirsync_message, memory allocated with ch_malloc was not freed when errors occurred. This adds two ch_free calls to ensure proper cleanup in those branches. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10376] New: 'this' seems to be duplicated in '8.4.5. Managing access with Groups' section
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10376 Issue ID: 10376 Summary: 'this' seems to be duplicated in '8.4.5. Managing access with Groups' section Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: truth_jp_4133(a)yahoo.co.jp Target Milestone: --- At the sentense 'One can then grant access to the members of this this group by adding appropriate by group clause to an access directive in slapd.conf(5).' in '8.4.5. Managing access with Groups' section, 'this' seems to be duplicated. https://www.openldap.org/doc/admin26/access-control.html -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10408] New: syncprov_op_search bailout: branch doesn't expect sop removal happened already
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10408 Issue ID: 10408 Summary: syncprov_op_search bailout: branch doesn't expect sop removal happened already 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: --- There are codepaths in syncprov_op_search that reach 'bailout:' when it's possible for syncprov_op_abandon to have snuck in and remove the 'syncops *' from the list in the meantime. However this branch always expects to find it there. Fix is coming. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10398] New: memberof and refint clash on subtree renames
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10398 Issue ID: 10398 Summary: memberof and refint clash on subtree renames 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: hyc(a)openldap.org Target Milestone: --- If a group and its members are under a subtree that got renamed, refint will trigger, and try to update all the relevant DNs. When it processes the group entry, it will issue Modifies to update the DNs of the group's members. The memberof overlay will see these modifies and start trying to update the corresponding memberof values but will only succeed halfway. It will try to delete the old memberof value from the old member DN's entry, which fails because the subtree has renamed all the entries. Then it will try to add the new memberof value to the new member DN's entry, which succeeds. Then eventually refint will try to process the member's. It will try to delete the old memberof value from the new entry, and add the new memberof value to the entry. This modify request fails because the new value is already present. The entry is left with a memberof value that points to the obsolete group DN. The solution is for refint to set the manageDsaIt control on its repair ops, and for memberof to ignore Modify requests with this control set. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10369] New: Error when trying to modify the olcDbCheckpoint attr: 'olcMultiProvider' cannot have multiple values
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10369 Issue ID: 10369 Summary: Error when trying to modify the olcDbCheckpoint attr: 'olcMultiProvider' cannot have multiple values Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: elecharny(a)apache.org Target Milestone: --- When trying to modify the olcDbCheckpoint, I get an error on the olcMultiProvider attribute Here are the logs I get: juil. 17 13:03:32 openldap1 slapd[17224]: conn=1012 op=3 MOD dn="olcDatabase={3}mdb,cn=config" juil. 17 13:03:32 openldap1 slapd[17224]: conn=1012 op=3 MOD attr=olcDbCheckpoint juil. 17 13:03:32 openldap1 slapd[17224]: slap_get_csn: conn=1012 op=3 generated new csn=20250717130332.671384Z#000000#00b#000000 manage=1 juil. 17 13:03:32 openldap1 slapd[17224]: slap_queue_csn: queueing 0x7f02cc104b80 20250717130332.671384Z#000000#00b#000000 juil. 17 13:03:32 openldap1 slapd[17224]: Entry (olcDatabase={3}mdb,cn=config), attribute 'olcMultiProvider' cannot have multiple values juil. 17 13:03:32 openldap1 slapd[17224]: conn=1012 op=3 RESULT tag=103 err=19 qtime=0.000008 etime=0.000185 text=attribute 'olcMultiProvider' cannot > juil. 17 13:03:32 openldap1 slapd[17224]: slap_graduate_commit_csn: removing 0x7f02cc104b80 20250717130332.671384Z#000000#00b#000000 juil. 17 13:03:32 openldap1 slapd[17224]: conn=1012 op=4 UNBIND Here is the content of the olcDatabase={3}mdb,cn=config entry: "olcDatabase={3}mdb,cn=config", { "objectClass":[ "olcDatabaseConfig", "olcMdbConfig" ], "olcDatabase":"{3}mdb", "olcDbDirectory":"/usr/local/openldap/data/worteks/", "olcSuffix":[ "o=service,o=worteks" ], "olcAccess":[ "{0}to * by dn=\"gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth\" read by dn=\"uid=repl,ou=security,o=service,o=worteks\" read by anonymous auth by * none break", "{1}to attrs=userPassword by * none", "{2}to dn.subtree=\"ou=security,o=service,o=worteks\" by * none", "{3}to * by * none" ], "olcAddContentAcl":true, "olcLimits":[ "{0}dn=\"uid=repl,ou=security,o=service,o=worteks\" size=unlimited time=unlimited", "{1}dn=\"gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth\" size=unlimited time=unlimited" ], "olcRootDN":"cn=admin,o=service,o=worteks", "olcRootPW":"secret", "olcSyncrepl":[ "{0}rid=012 provider=ldap://openldap1:10389 binddn=\"uid=repl,ou=security,o=service,o=worteks\" bindmethod=simple credentials=\"secret\" searchbase=\"o=service,o=worteks\" logbase=\"cn=accesslog\" logfilter=\"(&(objectClass=auditWriteObject)(reqResult=0))\" type=refreshAndPersist retry=\"5 +\" timeout=1 syncdata=accesslog", "{1}rid=011 provider=ldap://openldap2:10389 binddn=\"uid=repl,ou=security,o=service,o=worteks\" bindmethod=simple credentials=\"secret\" searchbase=\"o=service,o=worteks\" logbase=\"cn=accesslog\" logfilter=\"(&(objectClass=auditWriteObject)(reqResult=0))\" type=refreshAndPersist retry=\"5 +\" timeout=1 syncdata=accesslog" ], "olcMultiProvider":true, "olcDbCheckpoint":"1024 1", "olcDbNoSync":true, "olcDbIndex":[ "entryUUID eq", "objectClass eq", "entryCSN eq", "uid eq", "mailboxServiceIMAP eq", "mailboxServicePOP eq", "mailPrimaryAddress eq", "mailAlternativeAddress eq", "mailboxHiddenAlias eq" ], "olcDbMaxSize":137438953472 } In this context, I'm trying to modify the incorrect olcDbCheckpoint value from '1024 1' to '0 1', and the olcMultiProvider has only one value. -- You are receiving this mail because: You are on the CC list for the issue.

1 16

[Issue 10410] Buffer overflow in logging.c slapd module
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10410 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

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

29 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 4

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

29 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 4

[Issue 10432] New: filter with typo'ed attribute name causes 0 results
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10432 Issue ID: 10432 Summary: filter with typo'ed attribute name causes 0 results Product: OpenLDAP Version: 2.6.7 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: simon.leary42(a)proton.me Target Milestone: --- Here is a filter for posixAccount entries missing the sshPublicKey attribute: ``` (&(objectClass=posixAccount)(!(sshPublicKey=*))) ``` It works normally. If I made a typo and instead searched for entries missing some other bogus attribute name: ``` (&(objectClass=posixAccount)(!(ssshPublicKey=*))) ``` I get 0 results. None of my posixAccounts have an `ssshPublicKey` attribute, so I would think that the right half of my filter should be always true. So every posixAccount should be returned. Am I wrong to think that? Note: the `!(foo=*)` syntax comes from [stackoverflow](https://stackoverflow.com/questions/14441529/ldap-filter-for… -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10342] New: Potential Memory Leak in function mdb_txn_begin
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10342 Issue ID: 10342 Summary: Potential Memory Leak in function mdb_txn_begin Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: alexguo1023(a)gmail.com Target Milestone: --- Created attachment 1069 --> https://bugs.openldap.org/attachment.cgi?id=1069&action=edit Free txn->mt_u.dirty_list before freeing txn The function `mdb_txn_begin` allocates the dirty list via ```c txn->mt_u.dirty_list = malloc(sizeof(MDB_ID2) * MDB_IDL_UM_SIZE); ``` Later, when `txn != env->me_txn0`, it calls ```c free(txn); ``` without first freeing `txn->mt_u.dirty_list`. This orphaned allocation leads to a memory leak. -- 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