- openldap-bugs - openldap.org

[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 31 Mar '26

31 Mar '26

1 0

[Issue 10476] slapo-pcache crashes on cached bind attributes containing LDAP filter metachars
by openldap-its＠openldap.org 31 Mar '26

31 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10476 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs(a)openldap.org |ondra(a)mistotebe.net -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10476] slapo-pcache crashes on cached bind attributes containing LDAP filter metachars
by openldap-its＠openldap.org 31 Mar '26

31 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10476 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |2.6.14 Group|OpenLDAP-devs | Keywords|needs_review | --- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Not a security issue, CVE unnecessary. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[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 31 Mar '26

31 Mar '26

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

1 0

[Issue 10477] New: Reopening LMDB environment clears MDB_MAP_FULL error
by openldap-its＠openldap.org 31 Mar '26

31 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10477 Issue ID: 10477 Summary: Reopening LMDB environment clears MDB_MAP_FULL error Product: LMDB Version: 0.9.33 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: david.komarek(a)whalebone.io Target Milestone: --- Hello, We are using LMDB from multiple processes. One process performs writes, while several other processes (typically 4–12, depending on the number of CPUs) read from the same environment. The environment contains multiple (6) databases, and on average we write approximately 150 records per second. After some time, we begin encountering MDB_MAP_FULL errors on every write operation. Interestingly, after reopening the environment in the writer process, the error disappears and writing resumes successfully. Our configured map size is 4 GB, and we have not implemented any resizing strategy. Based on our observations, this does not seem strictly necessary, as there appears to be sufficient free space after reopening the environment. Reader processes do not keep read transactions open for long periods. We reset transactions using mdb_txn_reset after each read operation and reuse them via mdb_txn_renew. The environment is open with following flags for writing: MDB_WRITEMAP | MDB_NOTLS | MDB_NORDAHEAD | MDB_NOSYNC and for reading: MDB_RDONLY | MDB_NOTLS | MDB_NORDAHEAD. Could you please help us understand what might be causing this behavior and how we can prevent MDB_MAP_FULL errors without needing to reopen the environment? Thank you in advance. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[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 31 Mar '26

31 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10475 --- Comment #3 from Ondřej Kuzník <ondra(a)mistotebe.net> --- On Tue, Mar 31, 2026 at 02:15:26PM +0000, openldap-its(a)openldap.org wrote: > slapo-constraint is not a security control mechanism, it is a value control > mechanism. ACLs are used to control access. > > There is no issue here. If as they report, the overlay mistakenly allows one to store values not listed in the appropriate entry, it's still a valid issue. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[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 31 Mar '26

31 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10475 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Group|OpenLDAP-devs | Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Howard Chu <hyc(a)openldap.org> --- slapo-constraint is not a security control mechanism, it is a value control mechanism. ACLs are used to control access. There is no issue here. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10394] New: remove stroeder.com from support page
by openldap-its＠openldap.org 26 Mar '26

26 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10394 Issue ID: 10394 Summary: remove stroeder.com from support page Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- HI! for health reasons I gave up my business and I have retired . So it does no longer make sense to be listed on the support page. Ciao, Michael. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9967] New: Please register my company on the support page, again (www.openldap.org)
by openldap-its＠openldap.org 26 Mar '26

26 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=9967 Issue ID: 9967 Summary: Please register my company on the support page, again (www.openldap.org) Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: sjsong(a)aboutdap.kr Target Milestone: --- Howard Chu <hyc(a)openldap.org> 송상준 <sjsong(a)aboutdap.kr> Hi, you can submit a ticket against "website" in the ITS for this. Thanks. 송상준 wrote: > > Hello. openldap page administrater. > My name is sang jun song. > > I want to register my company on the support page. > I registered before, but it seems to have disappeared. > Our company has been attending ldapcon since 2015. > > The sysmas employees who attended the LDAPCON in 2019 may remember me. > > Please register my company on the support page. Please contact me if you need additional information.. > > thank you. > > Song. > > Registration phrase > > Seojindsa Co., Ltd. (Aboutdap Co., Ltd.)- Korea > > Provides consultancy, development, training and user support for OpenLDAP software in Korea. > > URL : seojindsa : www.seojindsa.kr > > ------------------------------------------------------ > (주) 어바웃답 기술영업팀 송상준 부장 > TEL. 010-9780-6746 > email: sjsong(a)aboutdap.kr > homepage: www.aboutdap.kr > ------------------------------------------------------- > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9717] New: The RADIUSOV overlay can be incorporated into OpenLDAP
by openldap-its＠openldap.org 26 Mar '26

26 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=9717 Issue ID: 9717 Summary: The RADIUSOV overlay can be incorporated into OpenLDAP Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: rdubner(a)symas.com Target Milestone: --- -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 8617] Seg-fault while using meta database and rwm overlay together
by openldap-its＠openldap.org 26 Mar '26

26 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=8617 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|nivanova(a)symas.com |bugs(a)openldap.org Target Milestone|2.7.0 |2.7.1 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9009] 2.7: Switch to LMDB v1.0
by openldap-its＠openldap.org 26 Mar '26

26 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=9009 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs(a)openldap.org |hyc(a)openldap.org -- 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 25 Mar '26

25 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10464 --- Comment #10 from tero.saarni(a)est.tech --- Sure! Here is the IPR notice for the included patches: The attached patch files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patches were developed by Tero Saarni tero.saarni(a)est.tech. I have not assigned rights and/or interest in this work to any party. Ericsson Software Technology AB hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. -- 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 25 Mar '26

25 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10464 --- Comment #9 from Ondřej Kuzník <ondra(a)mistotebe.net> --- On Tue, Mar 24, 2026 at 04:43:41PM +0000, openldap-its(a)openldap.org wrote: > I apologize for the delay in submitting the test cases for test022. I have > attached them now in case they are still useful. All tests pass with the latest > commits mentioned in this ticket! No worries at all, could you post an IPR statement here as well as per our contribution guidelines[0]? I can make sure it gets applied afterwards. [0]. https://openldap.org/devel/contributing.html#n-openldap Thanks a lot! -- 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 24 Mar '26

24 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10464 --- Comment #8 from tero.saarni(a)est.tech --- I apologize for the delay in submitting the test cases for test022. I have attached them now in case they are still useful. All tests pass with the latest commits mentioned in this ticket! -- 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 24 Mar '26

24 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10464 --- Comment #7 from tero.saarni(a)est.tech --- Created attachment 1132 --> https://bugs.openldap.org/attachment.cgi?id=1132&action=edit test-cases-for-test022 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10468] New: Certificate expiration
by openldap-its＠openldap.org 24 Mar '26

24 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10468 Issue ID: 10468 Summary: Certificate expiration Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: david.komarek(a)whalebone.io Target Milestone: --- Hello, the certificate for the https://git.openldap.org/openldap/openldap has expired at Saturday, March 21, 2026 at 12:48:46 AM Could you please renew it? -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[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

1 0

[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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs