openldap-bugs

openldap-bugs@openldap.org

1 participants
21509 discussions

[Issue 10464] slapd crashes in ppolicy when PasswordPolicyRequest control is sent with rejected operations
by openldap-its＠openldap.org 24 Mar '26

24 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10464 --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- • ef00132e by Ondřej Kuzník at 2026-03-19T19:59:00+00:00 ITS#10464 Also free Netscape policy control • b9e93b07 by Ondřej Kuzník at 2026-03-19T19:59:00+00:00 ITS#10464 Also free constructed DN • 8bddb75e by Ondřej Kuzník at 2026-03-19T19:59:00+00:00 ITS#10464 Make sure callback gets run every time it's needed • 01821166 by Ondřej Kuzník at 2026-03-19T19:59:00+00:00 ITS#10464 Free just the control we allocated -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8890] adapt to 64-bit time_t on systems with 32-bit long
by openldap-its＠openldap.org 19 Mar '26

19 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=8890 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |IN_PROGRESS --- Comment #19 from Ondřej Kuzník <ondra(a)mistotebe.net> --- I adapted Steve's patch, including addressing the issues I could find discussed here. https://git.openldap.org/openldap/openldap/-/merge_requests/842 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10464] slapd crashes in ppolicy when PasswordPolicyRequest control is sent with rejected operations
by openldap-its＠openldap.org 18 Mar '26

18 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10464 --- Comment #5 from tero.saarni(a)est.tech --- Sure, I will adapt the tests for test022. I'll submit a new patch shortly. Apologies for the ambiguous comment about versions, and glad to hear it is not happening with 2.6/2.5! What I should have written is that I tested only using the latest on master, but saw the code was not recent. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10464] slapd crashes in ppolicy when PasswordPolicyRequest control is sent with rejected operations
by openldap-its＠openldap.org 18 Mar '26

18 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10464 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=10013 Ever confirmed|0 |1 Status|UNCONFIRMED |IN_PROGRESS Group|OpenLDAP-devs | --- Comment #4 from Ondřej Kuzník <ondra(a)mistotebe.net> --- Thank you very much for the report! Could you maybe adjust test022 to include these scenarios? Don't worry if not, I can do it later. The wording of the last comment is slightly ambiguous, this doesn't happen on 2.6/2.5, only master. It is because the ITS#10013 patches are incomplete and after testing thoroughly I'll post a slightly different patch soon. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10462] New: MDB_NEXT/MDB_NEXT_NODUP/MDB_PREV_NODUP on cursor returns re-inserted key after mdb_del+mdb_put empties and repopulates DUPSORT db
by openldap-its＠openldap.org 18 Mar '26

18 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10462 Issue ID: 10462 Summary: MDB_NEXT/MDB_NEXT_NODUP/MDB_PREV_NODUP on cursor returns re-inserted key after mdb_del+mdb_put empties and repopulates DUPSORT db Product: LMDB Version: 0.9.35 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: github(a)nicwatson.org Target Milestone: --- Created attachment 1120 --> https://bugs.openldap.org/attachment.cgi?id=1120&action=edit C file that reproduces problem Overview: When a cursor is positioned on the only key in a MDB_DUPSORT database, and that key is deleted via mdb_del() then re-inserted via mdb_put() (both via the transaction API, not the cursor), subsequent mdb_cursor_get() with MDB_NEXT, MDB_NEXT_NODUP, or MDB_PREV_NODUP incorrectly returns the re-inserted key instead of MDB_NOTFOUND. This causes infinite loops in cursor traversal code. The bug does not occur when there are multiple unique keys in the database — only when the delete empties the B-tree entirely. Steps to Reproduce: 1. Create a MDB_DUPSORT database 2. Insert a single key with one or more dup values 3. Open a cursor and position it at the key via MDB_FIRST 4. Delete the key via mdb_del() (not mdb_cursor_del()) 5. Re-insert the same key via mdb_put() 6. Call mdb_cursor_get() with MDB_NEXT_NODUP Reproducer program attached. (build with cc -o repro repro.c mdb.c midl.c -I. -lpthread): Actual Results: mdb_cursor_get(MDB_NEXT_NODUP) returns MDB_SUCCESS and the cursor is positioned at the re-inserted key. In a traversal loop, this causes an infinite loop. Expected Results: mdb_cursor_get(MDB_NEXT_NODUP) should return MDB_NOTFOUND since there are no more unique keys after the cursor's position. Root Cause: When mdb_del() removes the only key, mdb_rebalance() empties the B-tree and clears C_INITIALIZED on all cursors (mdb.c line ~8407). The mdb_cursor_del0() function had already set C_DEL on other cursors at the same position (line ~8555). After mdb_put() re-inserts data, mdb_cursor_next() sees !C_INITIALIZED and falls through to mdb_cursor_first() (line 5967-5968), ignoring the fact that C_DEL indicates the cursor's entry was deleted. The same issue affects mdb_cursor_prev() (line 6049-6053). Proposed Fix: In mdb_cursor_next() and mdb_cursor_prev(), when C_INITIALIZED is not set, check for C_DEL first. If C_DEL is set, the cursor was positioned at a deleted entry and should not fall through to first/last: // mdb_cursor_next, line ~5967: if (!(mc->mc_flags & C_INITIALIZED)) { if (mc->mc_flags & C_DEL) return MDB_NOTFOUND; return mdb_cursor_first(mc, key, data); } // mdb_cursor_prev, line ~6049: if (!(mc->mc_flags & C_INITIALIZED)) { if (mc->mc_flags & C_DEL) return MDB_NOTFOUND; rc = mdb_cursor_last(mc, key, data); Build Date & Platform: LMDB 0.9.35, Linux 6.6.87, x86_64. Also confirmed on FreeBSD 14.3 with LMDB 0.9.33. -- You are receiving this mail because: You are on the CC list for the issue.

1 13

[Issue 10463] New: Windows write lock (me_wmutex) is recursive, allowing concurrent write txns and heap corruption
by openldap-its＠openldap.org 17 Mar '26

17 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10463 Issue ID: 10463 Summary: Windows write lock (me_wmutex) is recursive, allowing concurrent write txns and heap corruption 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, LMDB uses CreateMutexA for the write lock (me_wmutex) and reader lock (me_rmutex). Windows Mutex objects are inherently recursive: the owning thread can re-acquire the same mutex without blocking. This allows a single thread to open two write transactions concurrently, violating the single-writer invariant and corrupting the B-tree. The process crashes with `0xC0000374 STATUS_HEAP_CORRUPTION` on mdb_env_close or the next sync. On POSIX, pthread_mutex_lock on a default (non-recursive) mutex from the owning thread is undefined behavior (typically deadlocks), so this is not observable there. ## Steps to reproduce 1. Build the following program with MSVC: `cl /I libraries/liblmdb repro.c libraries/liblmdb/mdb.c libraries/liblmdb/midl.c Advapi32.lib` 2. Run repro.exe. ```c #include <stdio.h> #include <stdlib.h> #include <direct.h> #include "lmdb.h" int main(void) { MDB_env *env; MDB_txn *txn1, *txn2; MDB_dbi dbi1, dbi2; MDB_val key, val; int rc; mdb_env_create(&env); mdb_env_set_mapsize(env, 1024ULL * 1024 * 1024); _mkdir("testdb"); mdb_env_open(env, "testdb", 0, 0664); rc = mdb_txn_begin(env, NULL, 0, &txn1); printf("First write txn: rc=%d\n", rc); rc = mdb_txn_begin(env, NULL, 0, &txn2); printf("Second write txn: rc=%d\n", rc); mdb_dbi_open(txn1, NULL, 0, &dbi1); mdb_dbi_open(txn2, NULL, 0, &dbi2); key.mv_size = 4; val.mv_size = 4; key.mv_data = "key1"; val.mv_data = "val1"; mdb_put(txn1, dbi1, &key, &val, 0); key.mv_data = "key2"; val.mv_data = "val2"; mdb_put(txn2, dbi2, &key, &val, 0); mdb_txn_commit(txn2); mdb_txn_abort(txn1); mdb_env_close(env); return 0; } ``` ## Actual results Both mdb_txn_begin calls return MDB_SUCCESS. The process crashes with `0xC0000374 STATUS_HEAP_CORRUPTION` during mdb_env_close. ## Expected results The second mdb_txn_begin should block (matching POSIX behavior) or return an error. Two write transactions must never coexist. ## Analysis In mdb.c, the Windows `#ifdef _WIN32` block defines: ```c #define LOCK_MUTEX0(mutex) WaitForSingleObject(mutex, INFINITE) #define UNLOCK_MUTEX(mutex) ReleaseMutex(mutex) ``` The mutexes are created with CreateMutexA. Per Microsoft documentation: "After a thread obtains ownership of a mutex, it can specify the same mutex in repeated wait function calls without blocking its execution." This means LOCK_MUTEX0(env->me_wmutex) in mdb_txn_begin succeeds even when the calling thread already holds it. ## Proposed fix Replace Windows Mutex objects with Semaphore objects (initial count = 1, max count = 1). Semaphores are not recursive: if the calling thread calls WaitForSingleObject when the count is 0, it blocks. This matches the POSIX pthread_mutex_lock behavior. ```c /* Unlock macros: */ -#define pthread_mutex_unlock(x) ReleaseMutex(*x) -#define UNLOCK_MUTEX(mutex) ReleaseMutex(mutex) +#define pthread_mutex_unlock(x) ReleaseSemaphore(*x, 1, NULL) +#define UNLOCK_MUTEX(mutex) ReleaseSemaphore(mutex, 1, NULL) /* Lock creation (mdb_env_setup_locks): */ -env->me_rmutex = CreateMutexA(&mdb_all_sa, FALSE, name); +env->me_rmutex = CreateSemaphoreA(&mdb_all_sa, 1, 1, name); -env->me_wmutex = CreateMutexA(&mdb_all_sa, FALSE, name); +env->me_wmutex = CreateSemaphoreA(&mdb_all_sa, 1, 1, name); /* Lock opening (existing env): */ -env->me_rmutex = OpenMutexA(SYNCHRONIZE, FALSE, name); +env->me_rmutex = OpenSemaphoreA(SYNCHRONIZE|SEMAPHORE_MODIFY_STATE, FALSE, name); -env->me_wmutex = OpenMutexA(SYNCHRONIZE, FALSE, name); +env->me_wmutex = OpenSemaphoreA(SYNCHRONIZE|SEMAPHORE_MODIFY_STATE, FALSE, name); /* Copy thread mutex (mdb_env_copyfd1): */ -my.mc_mutex = CreateMutex(NULL, FALSE, NULL) +my.mc_mutex = CreateSemaphore(NULL, 1, 1, NULL) ``` No changes needed for LOCK_MUTEX0 (WaitForSingleObject works on both types), CloseHandle (works on both), or SignalObjectAndWait in pthread_cond_wait (signals a semaphore the same as a mutex). `SEMAPHORE_MODIFY_STATE` is required on OpenSemaphoreA so ReleaseSemaphore is permitted. ## Build information - Windows 11, MSVC 14.44 (Visual Studio 2022 Build Tools), x86-64 - Python 3.13.2 (MSC v.1942 64-bit) — original report via py-lmdb binding - Confirmed not observable on Linux (deadlocks instead of corrupting) -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10461] New: contrib/rbac: session filter construction uses fixed filterbuf[1024] with unbounded uid and role appends
by openldap-its＠openldap.org 12 Mar '26

12 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10461 Issue ID: 10461 Summary: contrib/rbac: session filter construction uses fixed filterbuf[1024] with unbounded uid and role appends Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: pengpeng(a)iscas.ac.cn Target Milestone: --- Hello OpenLDAP maintainers, I would like to report what appears to be a real current-head overflow in the contrib/slapd-modules/rbac module. I want to be careful about scope: this is a contrib/ module bug, not a core slapd claim. The vulnerable code builds a filter in a fixed stack buffer: char filterbuf[RBAC_BUFLEN]; ... strcat(filterbuf, "(&(objectClass=ftOperation)(|"); strcat(filterbuf, "(ftUsers="); strcat(filterbuf, sessp->uid.bv_val); strcat(filterbuf, ")"); for (i = 0; !BER_BVISEMPTY(&sessp->roles[i]); i++) { strcat(filterbuf, "(ftRoles="); strncat(filterbuf, sessp->roles[i].bv_val, sessp->roles[i].bv_len); strcat(filterbuf, ")"); } RBAC_BUFLEN is 1024. I checked the nearby input handling. The username validation routine constrains character classes, but I do not see a comparable length bound on uid, and the role list is parsed from BER as a variable-length caller-supplied set. So I do not see a current invariant that guarantees the concatenated (ftUsers=...) plus all (ftRoles=...) fragments stay within 1024 bytes before the strcat/strncat sequence runs. Why I think this should not be dismissed as a false positive: - fixed stack buffer - repeated unbounded concatenation - uid validation appears to constrain characters, not total accumulated filter length - roles are variable-length and iterated until an empty terminator I am keeping the claim narrow: this is a contrib/rbac session-filter construction bug, not a blanket statement about core OpenLDAP parsing. A straightforward fix would be to compute the required filter length up front or replace the concatenation chain with bounded formatting that rejects oversized accumulated filters. Best regards -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10457] New: slapd (2.6.8 / EL9 EPEL build) segfault in config_back_search() when bound as “data admin” and searching non-existent DN under cn=config
by openldap-its＠openldap.org 09 Mar '26

09 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10457 Issue ID: 10457 Summary: slapd (2.6.8 / EL9 EPEL build) segfault in config_back_search() when bound as “data admin” and searching non-existent DN under cn=config Product: OpenLDAP Version: 2.6.8 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: openldap(a)sdv.fr Target Milestone: --- Created attachment 1118 --> https://bugs.openldap.org/attachment.cgi?id=1118&action=edit ACLs and slapd backtrace slapd crashes (SIGSEGV) in the cn=config backend (config_back_search()) when a client performs a search with base DN cn=foobar,cn=config (non-existent entry), only when the client is bound as a "data" admin DN (e.g. cn=admin,dc=...) and the config database ACL denies access to everyone except local SASL/EXTERNAL (peercred root). slapd should not crash on an invalid or unauthorized request; it should return a normal LDAP error (e.g. LDAP_NO_SUCH_OBJECT or LDAP_INSUFFICIENT_ACCESS) without terminating. ============================== Environment ============================== OpenLDAP version / build : openldap-epel-2.6.8-2.el9.x86_64 (slapd /usr/sbin/slapd) Architecture : x86_64 Invocation : /usr/sbin/slapd -u ldap -h 'ldap:/// ldaps:/// ldapi:///' ============================== Steps to reproduce ============================== 1. Ensure the config database ACL matches the following (see file attached), i.e. only local SASL/EXTERNAL peercred root has manage, everyone else is none. 2. Perform a simple bind using the data admin DN (not a cn=config admin), then search with base DN cn=foobar,cn=config then slapd crashes (SIGSEGV). Used command to reproduce : ldapsearch -LLL -x -y "/var/ldap_admin_pwd" -D "cn=admin,dc=example,dc=com" -b "cn=foobar,cn=config" ============================== Backtrace ============================== slapd terminates with SIGSEGV in config_back_search() while handling the search. The crash happens at: "rs->sr_matched = last->ce_entry->e_name.bv_val;" in servers/slapd/bconfig.c:6877, apparently dereferencing an invalid last / last->ce_entry. You'll find complete backtrace attached (see file attached). ============================== Additional notes ============================== The crash is reproducible only when binding as the “data” admin DN and searching under cn=config with a non-existent DN. Anonymous search does not crash. This seems related to handling of sr_matched / matchedDN construction under access denial conditions in the config backend. Please advise if this is a known issue in 2.6.8 or if a patch is available, I can provide additional backtraces/logs as needed. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10459] New: Potential Null Pointer Dereference vulnerability in libraries/libldap/ldifutil.c
by openldap-its＠openldap.org 09 Mar '26

09 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10459 Issue ID: 10459 Summary: Potential Null Pointer Dereference vulnerability in libraries/libldap/ldifutil.c Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: 270186678(a)qq.com Target Milestone: --- Created attachment 1119 --> https://bugs.openldap.org/attachment.cgi?id=1119&action=edit npd vulnerability triggering steps Hello, I found a potential null pointer dereference in the function `ldap_parse_ldif_record_x` in `libraries/libldap/ldifutil.c`. The steps to trigger the issue are provided in the attached file (`npd vulnerability triggering steps.png`). Could you please help confirm whether this is a valid issue? Thank you for your time. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10440] New: memberof stop working on replication slaves after upgrade from 2.6.10
by openldap-its＠openldap.org 09 Mar '26

09 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10440 Issue ID: 10440 Summary: memberof stop working on replication slaves after upgrade from 2.6.10 Product: OpenLDAP Version: 2.6.12 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: statoon54(a)gmail.com Target Milestone: --- Hi, We encountered a problem yesterday when upgrading to OpenLDAP version 2.6.12.1 from 2.6.10.1. The memberOf overlay failed to delete or add memberOf on the replica servers. Replication is functioning correctly, memberOf on master works too, but adding or removing a group member from the master no longer triggers this change on the slave servers. I think there's a regression in this version when replication occurs. Standard configuration overlay memberof memberof-refint true memberof-dangling ignore # sortVals sortvals member # multivalued attributes stockage improvement multival member 1000,100 # # Sync prov Replica # # syncrepl directive syncrepl rid=001 provider=""xxxxxx" bindmethod=simple binddn="xxxxxx" credentials="xxxxx" searchbase="xxxxx" scope="sub" attrs="*,+" schemachecking=off type=refreshAndPersist retry="5 12 60 10 300 24 3600 +" timeout=60 network-timeout=0 keepalive=0:0:0 updateref xxxxxx --- Some trace show a 122 failed on memberof_value_modify if i add or delete a member. (works great since 2.6.10 on slaves) févr. 04 11:38:04 ldap-v4-slave-1-dev slapd[573178]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) csn=20260204103803.030751Z#000000#000#000000 tid 0x7f7a1d3fd6c0 févr. 04 11:38:04 ldap-v4-slave-1-dev slapd[573178]: syncrepl_entry: rid=001 be_search (0) févr. 04 11:38:04 ldap-v4-slave-1-dev slapd[573178]: syncrepl_entry: rid=001 cn=APP:EBOUTIQUE,ou=groups,dc=exemple,dc=fr févr. 04 11:38:04 ldap-v4-slave-1-dev slapd[573178]: slap_queue_csn: queueing 0x7f7a1443a5a0 20260204103803.030751Z#000000#000#000000 févr. 04 11:38:10 ldap-v4-slave-1-dev slapd[573178]: conn=-1 op=0: memberof_value_modify DN="uid=269015,ou=accounts,dc=exemple,dc=fr" delete memberOf="cn=APP:EBOUTIQUE,ou=groups,dc=exemple,dc=fr" failed err=122 févr. 04 11:38:10 ldap-v4-slave-1-dev slapd[573178]: slap_graduate_commit_csn: removing 0x7f7a1443a5a0 20260204103803.030751Z#000000#000#000000 févr. 04 11:38:10 ldap-v4-slave-1-dev slapd[573178]: syncrepl_entry: rid=001 be_modify cn=APP:EBOUTIQUE,ou=groups,dc=exemple,dc=fr (0) févr. 04 11:38:10 ldap-v4-slave-1-dev slapd[573178]: slap_queue_csn: queueing 0x7f7a14439de0 20260204103803.030751Z#000000#000#000000 févr. 04 11:38:10 ldap-v4-slave-1-dev slapd[573178]: slap_graduate_commit_csn: removing 0x7f7a14439de0 20260204103803.030751Z#000000#000#000000 -- You are receiving this mail because: You are on the CC list for the issue.

1 13

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