- openldap-bugs - openldap.org

[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

[Issue 10414] New: slapadd/modify adding a new entry to cn=config tries to re-add frontend
by openldap-its＠openldap.org 09 Mar '26

09 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10414 Issue ID: 10414 Summary: slapadd/modify adding a new entry to cn=config tries to re-add frontend 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: --- The tool API does not know that the frontend entry was already present so it tries and fails to add it. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10442] New: BAD_COPY_PASTE In function 'dds_db_open': Value 'di_max_ttl' might be 'di_min_ttl'
by openldap-its＠openldap.org 09 Mar '26

09 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10442 Issue ID: 10442 Summary: BAD_COPY_PASTE In function 'dds_db_open': Value 'di_max_ttl' might be 'di_min_ttl' Product: OpenLDAP Version: 2.6.8 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: tarasov.mv(a)ksb-soft.ru Target Milestone: --- Based on the description in the link, the logic is as follows: https://www.opennet.ru/cgi-bin/opennet/man.cgi?topic=slapo-dds&category=5 Both values can be specified in the slapd.conf configuration file, from where they will be read, but if neither is specified, then: dds-max-ttl will default to 86400 seconds = 1 day (i.e., DDS_RF2589_DEFAULT_TTL). dds-min-ttl will default to 0, indicating that the lower TTL limit is not set. What we see in the implementation code: If di->di_max_ttl == 0 (does this mean "di->di_max_ttl is not defined"?), then di->di_max_ttl will receive DDS_RF2589_DEFAULT_TTL. That is, the implementation actually sets what should be the default if the value is undefined. If di->di_min_ttl == 0 (does this mean "di->di_min_ttl is undefined"?), then di->di_max_ttl receives DDS_RF2589_DEFAULT_TTL. That is, if the value is undefined (is 0 at the time of checking), the implementation sets di->di_max_ttl to the default value. I believe there will be incorrect behavior in the following scenario: if, before these conditions are met, di->di_max_ttl == 100000, and di->di_min_ttl == 0, then di->di_max_ttl will be overwritten with the default 86400 for no apparent reason. Besides this: The current dds_db_open is executed after dds_db_init, where di->di_min_ttl is missing from the definition, but instead is written twice: di->di_max_ttl = DDS_RF2589_DEFAULT_TTL; di->di_max_ttl = DDS_RF2589_DEFAULT_TTL; This, in my opinion, is also a sign of bad_copy_paste. I think the status is Confirmed+Major. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10447] New: memory leak in the LDAP chaining behavior control parser (`ldap_chain_parse_ctrl`)
by openldap-its＠openldap.org 09 Mar '26

09 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10447 Issue ID: 10447 Summary: memory leak in the LDAP chaining behavior control parser (`ldap_chain_parse_ctrl`) Product: OpenLDAP Version: 2.6.12 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: kangyang126(a)gmail.com Target Milestone: --- # Memory Leak Fix Report: LDAP Chain Control Parser ## Executive Summary Fixed a memory leak in the LDAP chaining behavior control parser (`ldap_chain_parse_ctrl`) that was leaking 80 bytes per failed control parsing operation. The leak was detected by LeakSanitizer during fuzzing operations. ## Issue Details **File**: `servers/slapd/back-ldap/chain.c` **Function**: `ldap_chain_parse_ctrl` ## Root Cause Analysis The `ldap_chain_parse_ctrl` function allocates a BER (Basic Encoding Rules) structure at line 2222: ```c ber = ber_init( &ctrl->ldctl_value ); ``` This allocation is properly freed at the end of the function (line 2303) in the success path: ```c (void) ber_free( ber, 1 ); ``` However, the function contains **five error handling paths** that return `LDAP_PROTOCOL_ERROR` before reaching the cleanup code, causing the BER structure to leak in these failure scenarios: 1. **Invalid resolveBehavior tag** (line 2231-2235) 2. **Unknown resolveBehavior value** (line 2254-2258) 3. **continuationBehavior decoding error** (line 2263-2267) 4. **Unknown continuationBehavior value** (line 2291-2295) 5. **Final sequence parsing error** (line 2298-2302) ## LeakSanitizer Stack Trace ``` ==76274==ERROR: LeakSanitizer: detected memory leaks Direct leak of 80 byte(s) in 1 object(s) allocated from: #0 0x55dd3756d7d9 in calloc #1 0x55dd37b62198 in ber_memcalloc_x #2 0x55dd37b62198 in ber_memcalloc #3 0x55dd37b5def2 in ber_alloc_t #4 0x55dd37b5def2 in ber_init #5 0x55dd37a14e97 in ldap_chain_parse_ctrl (chain.c:2222) #6 0x55dd3771714c in slap_parse_ctrl #7 0x55dd37718111 in get_ctrls2 #8 0x55dd37752c26 in do_add ``` ## Solution Implemented Added `ber_free( ber, 1 );` before each early return statement to ensure proper cleanup in all code paths: ### Fix 1: resolveBehavior decoding error (line 2232) ```diff diff --git a/servers/slapd/back-ldap/chain.c b/servers/slapd/back-ldap/chain.c index a789e7a..8fdd7a5 100644 --- a/servers/slapd/back-ldap/chain.c +++ b/servers/slapd/back-ldap/chain.c @@ -2229,6 +2229,7 @@ ldap_chain_parse_ctrl( /* FIXME: since the whole SEQUENCE is optional, * should we accept no enumerations at all? */ if ( tag != LBER_ENUMERATED ) { + ber_free( ber, 1 ); rs->sr_text = "Chaining behavior control: resolveBehavior decoding error"; return LDAP_PROTOCOL_ERROR; } @@ -2251,6 +2252,7 @@ ldap_chain_parse_ctrl( break; default: + ber_free( ber, 1 ); rs->sr_text = "Chaining behavior control: unknown resolveBehavior"; return LDAP_PROTOCOL_ERROR; } @@ -2259,6 +2261,7 @@ ldap_chain_parse_ctrl( if ( tag == LBER_ENUMERATED ) { tag = ber_scanf( ber, "e", &behavior ); if ( tag == LBER_ERROR ) { + ber_free( ber, 1 ); rs->sr_text = "Chaining behavior control: continuationBehavior decoding error"; return LDAP_PROTOCOL_ERROR; } @@ -2286,12 +2289,14 @@ ldap_chain_parse_ctrl( break; default: + ber_free( ber, 1 ); rs->sr_text = "Chaining behavior control: unknown continuationBehavior"; return LDAP_PROTOCOL_ERROR; } } if ( ( ber_scanf( ber, /* { */ "}") ) == LBER_ERROR ) { + ber_free( ber, 1 ); rs->sr_text = "Chaining behavior control: decoding error"; return LDAP_PROTOCOL_ERROR; } ``` ## Harness ``` #define _GNU_SOURCE /* For memfd_create */ #include "portable.h" #include <stdio.h> #include <string.h> #include <unistd.h> #include <fcntl.h> #include <sys/mman.h> #include <sys/types.h> #include <signal.h> #include "slap.h" /* 1. Fix function declarations to match return types in OpenLDAP source code */ extern void slap_sl_mem_init( void ); extern int slapd_daemon_init( const char *urls ); extern int extops_init( void ); /* Returns int */ extern void lutil_passwd_init( void ); extern int slap_init( int mode, const char *name ); extern int read_config( const char *fname, const char *dname ); extern int connections_init( void ); /* Returns int */ extern int slap_startup( Backend *be ); void slapd_daemon_nothread( void ) {} extern int ldap_pvt_thread_initialize( void ); /* Returns int */ extern void* ldap_pvt_thread_pool_context( void ); extern void* connection_read_thread( void *ctx, void *arg ); extern void connection_closing( Connection *c, const char *why ); extern int connection_resched( Connection *c ); extern Connection* connection_init( int sfd, Listener *l, const char *authid, const char *dns, int flags, slap_ssf_t ssf, struct berval *authid_out ); extern ldap_pvt_thread_pool_t connection_pool; static Listener *global_listener = NULL; static struct berval authid_bv = {0, ""}; int LLVMFuzzerInitialize(int *argc, char ***argv) { signal(SIGPIPE, SIG_IGN); slap_debug = 0; slap_sl_mem_init(); if ( 0 != slapd_daemon_init("ldapi://%2Ftmp%2Ffuzz.sock") ) return 1; extops_init(); lutil_passwd_init(); if ( slap_init(SLAP_SERVER_MODE, "slapd-fuzz") ) return 2; read_config( NULL, NULL ); connections_init(); slap_startup(NULL); slapd_daemon_nothread(); ldap_pvt_thread_initialize(); global_listener = slapd_get_listeners()[0]; if (!global_listener) return 3; return 0; } #include <sys/socket.h> int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size) { if (Size < 2 || Size > 65536) return 0; /* 2. Use socketpair to simulate socket read/write */ int sv[2]; if (socketpair(AF_UNIX, SOCK_STREAM, 0, sv) < 0) return 0; if (write(sv[0], Data, Size) != (ssize_t)Size) { close(sv[0]); close(sv[1]); return 0; } /* Close write end so server receives EOF after reading data */ close(sv[0]); /* 3. Create connection (server uses sv[1]) */ Connection *c = connection_init(sv[1], global_listener, "fuzz", "IP=127.0.0.1", 0, 0, &authid_bv); if (!c) { close(sv[1]); return 0; } void* ctx = ldap_pvt_thread_pool_context(); /* Execute parsing logic */ connection_read_thread(ctx, (void*)(long)sv[1]); /* Wait for thread pool to complete all tasks to prevent background threads from accessing freed connection */ int active = 0, pending = 0; do { ldap_pvt_thread_pool_query(&connection_pool, LDAP_PVT_THREAD_POOL_PARAM_PENDING, &pending); ldap_pvt_thread_pool_query(&connection_pool, LDAP_PVT_THREAD_POOL_PARAM_ACTIVE, &active); if (active == 0 && pending == 0) break; ldap_pvt_thread_yield(); } while (1); /* 4. Thoroughly clean up manually, avoiding unstable macros * Directly manipulate queue pointers to ensure no 'error: use of undeclared identifier o_next' */ Operation *op; while ((op = LDAP_STAILQ_FIRST(&c->c_ops)) != NULL) { LDAP_STAILQ_REMOVE_HEAD(&c->c_ops, o_next); LDAP_STAILQ_NEXT(op, o_next) = NULL; slap_op_free(op, ctx); } LDAP_STAILQ_INIT(&c->c_ops); /* Close and reclaim Connection memory */ connection_closing(c, "fuzz complete"); connection_resched(c); /* ldap_pvt_thread_pool_resume(&connection_pool); */ return 0; } ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10451] New: Sporadic failures in test lloadd/test001
by openldap-its＠openldap.org 09 Mar '26

09 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10451 Issue ID: 10451 Summary: Sporadic failures in test lloadd/test001 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: --- It seems the connection is made but lloadd never gets the memo so it doesn't proceed with setting up the rest. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10427] New: ldapsearch(1) incorrectly documents OID-based search option
by openldap-its＠openldap.org 09 Mar '26

09 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10427 Issue ID: 10427 Summary: ldapsearch(1) incorrectly documents OID-based search option Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: michael.osipov(a)innomotics.com Target Milestone: --- Created attachment 1109 --> https://bugs.openldap.org/attachment.cgi?id=1109&action=edit Git-formatted patch Docs/manpage for -E say: [!]<oid>[=:<value>|::<b64value>] But it does not work: > $ ldapsearch -Y GSSAPI -O maxssf=1 -E '!1.2.840.113556.1.4.1340::MAYSBAAAAAI=' -o ldif-wrap=no -H ldap://innomotics.net "(objectClass=dnsNode1)" Invalid search extension name: 1.2.840.113556.1.4.1340::MAYSBAAAAAI It is '=::': > $ ldapsearch -Y GSSAPI -O maxssf=1 -E '!1.2.840.113556.1.4.1340=::MAYSBAAAAAI=' -o ldif-wrap=no -H ldap://innomotics.net "(objectClass=dnsNode1)" > SASL/GSSAPI authentication started Attached is a simple patch to fix it. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10445] New: memroy leak in get_mra
by openldap-its＠openldap.org 09 Mar '26

09 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10445 Issue ID: 10445 Summary: memroy leak in get_mra Product: OpenLDAP Version: 2.6.12 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: kangyang126(a)gmail.com Target Milestone: --- # ASAN Leak Report: Extensible Matching Rule Assertion ## Component * **File:** `servers/slapd/mra.c` * **Function:** `get_mra` ## Issue Description **LeakSanitizer Error:** Memory leak detected when parsing a matching rule assertion (MRA). ```shell ==179518==ERROR: LeakSanitizer: detected memory leaks Direct leak of 58 byte(s) in 1 object(s) allocated from: #0 0x555555963614 in malloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:67:3 #1 0x555555f57804 in ber_memalloc_x /src/openldap/libraries/liblber/memory.c:228:9 #2 0x555555b3a3a3 in slap_sl_malloc /src/openldap/servers/slapd/sl_malloc.c:302:12 #3 0x555555b2b465 in slap_bv2tmp_ad /src/openldap/servers/slapd/ad.c:808:4 #4 0x555555a0a2a5 in get_mra /src/openldap/servers/slapd/mra.c:151:18 #5 0x5555559ea994 in get_filter0 /src/openldap/servers/slapd/filter.c:286:9 #6 0x5555559baea5 in str2filter_x /src/openldap/servers/slapd/str2filter.c:65:7 #7 0x5555559bb1b7 in str2filter /src/openldap/servers/slapd/str2filter.c:83:9 #8 0x555555b61174 in authzPrettyNormal /src/openldap/servers/slapd/saslauthz.c:804:7 #9 0x555555b617db in authzPretty /src/openldap/servers/slapd/saslauthz.c:905:7 #10 0x555555a86b16 in ordered_value_pretty /src/openldap/servers/slapd/value.c:511:7 #11 0x555555b40939 in slap_mods_check /src/openldap/servers/slapd/modify.c:577:11 #12 0x555555b3efa1 in do_modify /src/openldap/servers/slapd/modify.c:165:15 #13 0x5555559e055d in connection_operation /src/openldap/servers/slapd/connection.c:1137:7 #14 0x5555559df327 in connection_read_thread /src/openldap/servers/slapd/connection.c:1289:14 #15 0x5555559a769a in LLVMFuzzerTestOneInput /src/fuzz_slapd.c:88:5 ``` The function `get_mra` allocates memory for the `MatchingRuleAssertion` structure and its members (such as `ma_desc` or `ma_value`). If a logical error occurs *after* these allocations (e.g., "matching rule not recognized" or "inappropriate matching"), the function previously returned an error code immediately without freeing the allocated memory. ## Fix Implemented a `return_error` label with cleanup logic. * Replaced direct `return` statements in error paths with `goto return_error`. * The `return_error` block calls `mra_free()` to release all resources allocated for the MRA before returning the error code. ## Diff ```diff diff --git a/servers/slapd/mra.c b/servers/slapd/mra.c index 2295c13..55adfc3 100644 --- a/servers/slapd/mra.c +++ b/servers/slapd/mra.c @@ -33,6 +33,8 @@ mra_free( MatchingRuleAssertion *mra, int freeit ) { + if ( mra == NULL ) return; + #ifdef LDAP_COMP_MATCH /* free component assertion */ if ( mra->ma_rule->smr_usage & SLAP_MR_COMPONENT && mra->ma_cf ) { @@ -158,7 +160,8 @@ get_mra( ma.ma_rule = mr_bvfind( &rule_text ); if( ma.ma_rule == NULL ) { *text = "matching rule not recognized"; - return LDAP_INAPPROPRIATE_MATCHING; + rc = LDAP_INAPPROPRIATE_MATCHING; + goto return_error; } } @@ -168,7 +171,8 @@ get_mra( */ if ( ma.ma_desc == NULL ) { *text = "no matching rule or type"; - return LDAP_INAPPROPRIATE_MATCHING; + rc = LDAP_INAPPROPRIATE_MATCHING; + goto return_error; } if ( ma.ma_desc->ad_type->sat_equality != NULL && @@ -180,14 +184,16 @@ get_mra( } else { *text = "no appropriate rule to use for type"; - return LDAP_INAPPROPRIATE_MATCHING; + rc = LDAP_INAPPROPRIATE_MATCHING; + goto return_error; } } if ( ma.ma_desc != NULL ) { if( !mr_usable_with_at( ma.ma_rule, ma.ma_desc->ad_type ) ) { *text = "matching rule use with this attribute not appropriate"; - return LDAP_INAPPROPRIATE_MATCHING; + rc = LDAP_INAPPROPRIATE_MATCHING; + goto return_error; } } @@ -200,18 +206,18 @@ get_mra( SLAP_MR_EXT|SLAP_MR_VALUE_OF_ASSERTION_SYNTAX, &value, &ma.ma_value, text, op->o_tmpmemctx ); - if( rc != LDAP_SUCCESS ) return rc; + if( rc != LDAP_SUCCESS ) goto return_error; #ifdef LDAP_COMP_MATCH /* Check If this attribute is aliased */ if ( is_aliased_attribute && ma.ma_desc && ( aa = is_aliased_attribute ( ma.ma_desc ) ) ) { rc = get_aliased_filter ( op, &ma, aa, text ); - if ( rc != LDAP_SUCCESS ) return rc; + if ( rc != LDAP_SUCCESS ) goto return_error; } else if ( ma.ma_rule && ma.ma_rule->smr_usage & SLAP_MR_COMPONENT ) { /* Matching Rule for Component Matching */ rc = get_comp_filter( op, &ma.ma_value, &ma.ma_cf, text ); - if ( rc != LDAP_SUCCESS ) return rc; + if ( rc != LDAP_SUCCESS ) goto return_error; } #endif @@ -228,4 +234,8 @@ get_mra( } return LDAP_SUCCESS; + +return_error: + mra_free( op, &ma, 0 ); + return rc; } ``` ## Harness ``` #define _GNU_SOURCE /* For memfd_create */ #include "portable.h" #include <stdio.h> #include <string.h> #include <unistd.h> #include <fcntl.h> #include <sys/mman.h> #include <sys/types.h> #include <signal.h> #include "slap.h" /* 1. Fix function declarations to match return types in OpenLDAP source code */ extern void slap_sl_mem_init( void ); extern int slapd_daemon_init( const char *urls ); extern int extops_init( void ); /* Returns int */ extern void lutil_passwd_init( void ); extern int slap_init( int mode, const char *name ); extern int read_config( const char *fname, const char *dname ); extern int connections_init( void ); /* Returns int */ extern int slap_startup( Backend *be ); void slapd_daemon_nothread( void ) {} extern int ldap_pvt_thread_initialize( void ); /* Returns int */ extern void* ldap_pvt_thread_pool_context( void ); extern void* connection_read_thread( void *ctx, void *arg ); extern void connection_closing( Connection *c, const char *why ); extern int connection_resched( Connection *c ); extern Connection* connection_init( int sfd, Listener *l, const char *authid, const char *dns, int flags, slap_ssf_t ssf, struct berval *authid_out ); extern ldap_pvt_thread_pool_t connection_pool; static Listener *global_listener = NULL; static struct berval authid_bv = {0, ""}; int LLVMFuzzerInitialize(int *argc, char ***argv) { signal(SIGPIPE, SIG_IGN); slap_debug = 0; slap_sl_mem_init(); if ( 0 != slapd_daemon_init("ldapi://%2Ftmp%2Ffuzz.sock") ) return 1; extops_init(); lutil_passwd_init(); if ( slap_init(SLAP_SERVER_MODE, "slapd-fuzz") ) return 2; read_config( NULL, NULL ); connections_init(); slap_startup(NULL); slapd_daemon_nothread(); ldap_pvt_thread_initialize(); global_listener = slapd_get_listeners()[0]; if (!global_listener) return 3; return 0; } #include <sys/socket.h> int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size) { if (Size < 2 || Size > 65536) return 0; /* 2. Use socketpair to simulate socket read/write */ int sv[2]; if (socketpair(AF_UNIX, SOCK_STREAM, 0, sv) < 0) return 0; if (write(sv[0], Data, Size) != (ssize_t)Size) { close(sv[0]); close(sv[1]); return 0; } /* Close write end so server receives EOF after reading data */ close(sv[0]); /* 3. Create connection (server uses sv[1]) */ Connection *c = connection_init(sv[1], global_listener, "fuzz", "IP=127.0.0.1", 0, 0, &authid_bv); if (!c) { close(sv[1]); return 0; } void* ctx = ldap_pvt_thread_pool_context(); /* Execute parsing logic */ connection_read_thread(ctx, (void*)(long)sv[1]); /* Wait for thread pool to complete all tasks to prevent background threads from accessing freed connection */ int active = 0, pending = 0; do { ldap_pvt_thread_pool_query(&connection_pool, LDAP_PVT_THREAD_POOL_PARAM_PENDING, &pending); ldap_pvt_thread_pool_query(&connection_pool, LDAP_PVT_THREAD_POOL_PARAM_ACTIVE, &active); if (active == 0 && pending == 0) break; ldap_pvt_thread_yield(); } while (1); /* 4. Thoroughly clean up manually, avoiding unstable macros * Directly manipulate queue pointers to ensure no 'error: use of undeclared identifier o_next' */ Operation *op; while ((op = LDAP_STAILQ_FIRST(&c->c_ops)) != NULL) { LDAP_STAILQ_REMOVE_HEAD(&c->c_ops, o_next); LDAP_STAILQ_NEXT(op, o_next) = NULL; slap_op_free(op, ctx); } LDAP_STAILQ_INIT(&c->c_ops); /* Close and reclaim Connection memory */ connection_closing(c, "fuzz complete"); connection_resched(c); /* ldap_pvt_thread_pool_resume(&connection_pool); */ return 0; } ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10443] slap_sasl_mechs Heap Buffer Overflow due to race condition
by openldap-its＠openldap.org 09 Mar '26

09 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10443 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 10450] New: memory leak in parseAssert
by openldap-its＠openldap.org 09 Mar '26

09 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10450 Issue ID: 10450 Summary: memory leak in parseAssert Product: OpenLDAP Version: 2.6.12 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: kangyang126(a)gmail.com Target Milestone: --- # Memory Leak Fix: Control Parsing Error Handling ## Summary Fixed a memory leak in LDAP control parsing caused by improper error handling in `parseAssert` and `parseValuesReturnFilter` functions. The issue resulted in double response sending and disrupted the normal resource cleanup flow. --- ## Problem Description ### Memory Leak Details - **Location**: `servers/slapd/controls.c` - **Affected Functions**: `parseAssert()`, `parseValuesReturnFilter()` - **Leak Size**: 24 bytes per occurrence (Filter structure) - **Trigger**: Control parsing errors or incomplete operation cleanup ### Stack Trace ``` Direct leak of 24 byte(s) in 1 object(s) allocated from: #0 malloc #1 ber_memalloc_x /src/openldap/libraries/liblber/memory.c:228 #2 ch_malloc /src/openldap/servers/slapd/ch_malloc.c:54 #3 get_filter0 /src/openldap/servers/slapd/filter.c:312 #4 get_filter_list /src/openldap/servers/slapd/filter.c:350 #5 get_filter0 /src/openldap/servers/slapd/filter.c:244 #6 get_filter_list /src/openldap/servers/slapd/filter.c:350 #7 get_filter0 /src/openldap/servers/slapd/filter.c:231 #8 parseAssert /src/openldap/servers/slapd/controls.c:1435 #9 slap_parse_ctrl /src/openldap/servers/slapd/controls.c:738 #10 get_ctrls2 /src/openldap/servers/slapd/controls.c:929 #11 do_search /src/openldap/servers/slapd/search.c:194 #12 connection_operation /src/openldap/servers/slapd/connection.c:1137 #13 connection_read_thread /src/openldap/servers/slapd/connection.c:1289 ``` --- ## Root Cause Analysis ### Architectural Issue Control parser functions were violating the separation of concerns by: 1. **Sending LDAP responses directly** instead of returning error codes 2. **Manually freeing resources** in error paths instead of relying on cleanup infrastructure 3. **Breaking the normal cleanup flow** established by `slap_op_free()` → `slap_free_ctrls()` ### Code Flow Analysis #### Before Fix - Incorrect Flow: ``` 1. get_ctrls2() calls slap_parse_ctrl() 2. slap_parse_ctrl() calls parseAssert() 3. parseAssert() calls get_filter() which allocates Filter 4. get_filter() returns error 5. parseAssert() sends LDAP response ← FIRST SEND (wrong!) 6. parseAssert() frees op->o_assertion ← Manual cleanup (wrong!) 7. parseAssert() returns error to slap_parse_ctrl() 8. slap_parse_ctrl() returns error to get_ctrls2() 9. get_ctrls2() goes to return_results: 10. get_ctrls2() sends LDAP response ← SECOND SEND (duplicate!) 11. Operation cleanup may or may not happen 12. If cleanup fails → MEMORY LEAK ``` #### After Fix - Correct Flow: ``` 1. get_ctrls2() calls slap_parse_ctrl() 2. slap_parse_ctrl() calls parseAssert() 3. parseAssert() calls get_filter() which allocates Filter 4. get_filter() returns error 5. parseAssert() returns error (no send, no cleanup) 6. slap_parse_ctrl() returns error to get_ctrls2() 7. get_ctrls2() goes to return_results: 8. get_ctrls2() sends LDAP response ← SINGLE SEND (correct!) 9. Eventually slap_op_free() is called 10. slap_op_free() calls slap_free_ctrls() 11. slap_free_ctrls() properly frees all resources 12. No memory leak ``` --- ## The Fix ### Files Modified - `servers/slapd/controls.c` ### Changes Made #### 1. parseAssert() - Lines 1435-1451 **Removed:** ```c if( rs->sr_err != LDAP_SUCCESS ) { if( rs->sr_err == SLAPD_DISCONNECT ) { rs->sr_err = LDAP_PROTOCOL_ERROR; send_ldap_disconnect( op, rs ); rs->sr_err = SLAPD_DISCONNECT; } else { send_ldap_result( op, rs ); } if( op->o_assertion != NULL ) { filter_free_x( op, op->o_assertion, 1 ); op->o_assertion = NULL; } return rs->sr_err; } ``` **Replaced with:** ```c if( rs->sr_err != LDAP_SUCCESS ) { return rs->sr_err; } ``` #### 2. parseValuesReturnFilter() - Lines 1630-1647 **Removed:** ```c if( rs->sr_err != LDAP_SUCCESS ) { if( rs->sr_err == SLAPD_DISCONNECT ) { rs->sr_err = LDAP_PROTOCOL_ERROR; send_ldap_disconnect( op, rs ); rs->sr_err = SLAPD_DISCONNECT; } else { send_ldap_result( op, rs ); } if( op->o_vrFilter != NULL) { vrFilter_free( op, op->o_vrFilter ); op->o_vrFilter = NULL; } } ``` **Replaced with:** ```c if( rs->sr_err != LDAP_SUCCESS ) { return rs->sr_err; } ``` --- ## Technical Details ### Cleanup Infrastructure The proper cleanup is handled by: 1. **slap_op_free()** (`servers/slapd/operation.c:80`) - Called when operations are freed from connection queue - Invokes `slap_free_ctrls(op, op->o_ctrls)` at line 102 2. **slap_free_ctrls()** (`servers/slapd/controls.c:608`) - Checks `if(ctrls == op->o_ctrls)` to ensure cleaning operation controls - Frees `op->o_assertion` via `filter_free_x()` (lines 615-617) - Frees `op->o_vrFilter` via `vrFilter_free()` (lines 619-621) - Handles NULL checks properly, safe for partial parsing ## Harness ``` #define _GNU_SOURCE /* For memfd_create */ #include "portable.h" #include <stdio.h> #include <string.h> #include <unistd.h> #include <fcntl.h> #include <sys/mman.h> #include <sys/types.h> #include <signal.h> #include "slap.h" /* 1. Fix function declarations to match return types in OpenLDAP source code */ extern void slap_sl_mem_init( void ); extern int slapd_daemon_init( const char *urls ); extern int extops_init( void ); /* Returns int */ extern void lutil_passwd_init( void ); extern int slap_init( int mode, const char *name ); extern int read_config( const char *fname, const char *dname ); extern int connections_init( void ); /* Returns int */ extern int slap_startup( Backend *be ); void slapd_daemon_nothread( void ) {} extern int ldap_pvt_thread_initialize( void ); /* Returns int */ extern void* ldap_pvt_thread_pool_context( void ); extern void* connection_read_thread( void *ctx, void *arg ); extern void connection_closing( Connection *c, const char *why ); extern int connection_resched( Connection *c ); extern Connection* connection_init( int sfd, Listener *l, const char *authid, const char *dns, int flags, slap_ssf_t ssf, struct berval *authid_out ); extern ldap_pvt_thread_pool_t connection_pool; static Listener *global_listener = NULL; static struct berval authid_bv = {0, ""}; int LLVMFuzzerInitialize(int *argc, char ***argv) { signal(SIGPIPE, SIG_IGN); slap_debug = 0; slap_sl_mem_init(); if ( 0 != slapd_daemon_init("ldapi://%2Ftmp%2Ffuzz.sock") ) return 1; extops_init(); lutil_passwd_init(); if ( slap_init(SLAP_SERVER_MODE, "slapd-fuzz") ) return 2; read_config( NULL, NULL ); connections_init(); slap_startup(NULL); slapd_daemon_nothread(); ldap_pvt_thread_initialize(); global_listener = slapd_get_listeners()[0]; if (!global_listener) return 3; return 0; } #include <sys/socket.h> int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size) { if (Size < 2 || Size > 65536) return 0; /* 2. Use socketpair to simulate socket read/write */ int sv[2]; if (socketpair(AF_UNIX, SOCK_STREAM, 0, sv) < 0) return 0; if (write(sv[0], Data, Size) != (ssize_t)Size) { close(sv[0]); close(sv[1]); return 0; } /* Close write end so server receives EOF after reading data */ close(sv[0]); /* 3. Create connection (server uses sv[1]) */ Connection *c = connection_init(sv[1], global_listener, "fuzz", "IP=127.0.0.1", 0, 0, &authid_bv); if (!c) { close(sv[1]); return 0; } void* ctx = ldap_pvt_thread_pool_context(); /* Execute parsing logic */ connection_read_thread(ctx, (void*)(long)sv[1]); /* Wait for thread pool to complete all tasks to prevent background threads from accessing freed connection */ int active = 0, pending = 0; do { ldap_pvt_thread_pool_query(&connection_pool, LDAP_PVT_THREAD_POOL_PARAM_PENDING, &pending); ldap_pvt_thread_pool_query(&connection_pool, LDAP_PVT_THREAD_POOL_PARAM_ACTIVE, &active); if (active == 0 && pending == 0) break; ldap_pvt_thread_yield(); } while (1); /* 4. Thoroughly clean up manually, avoiding unstable macros * Directly manipulate queue pointers to ensure no 'error: use of undeclared identifier o_next' */ Operation *op; while ((op = LDAP_STAILQ_FIRST(&c->c_ops)) != NULL) { LDAP_STAILQ_REMOVE_HEAD(&c->c_ops, o_next); LDAP_STAILQ_NEXT(op, o_next) = NULL; slap_op_free(op, ctx); } LDAP_STAILQ_INIT(&c->c_ops); /* Close and reclaim Connection memory */ connection_closing(c, "fuzz complete"); connection_resched(c); /* ldap_pvt_thread_pool_resume(&connection_pool); */ return 0; } ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 10258] New: test050 failure: connection_close race?
by openldap-its＠openldap.org 09 Mar '26

09 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10258 Issue ID: 10258 Summary: test050 failure: connection_close race? 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: --- Created attachment 1032 --> https://bugs.openldap.org/attachment.cgi?id=1032&action=edit tail of slapd log Running test050 repeatedly, the slapd managed to get itself into an apparent inconsistency in the connections structure. The logs suggest that there might be a race closing the connection. Unfortunately the sanitiser didn't initiate a core dump in this case. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 10413] New: Consumer prepares cookie too early
by openldap-its＠openldap.org 09 Mar '26

09 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10413 Issue ID: 10413 Summary: Consumer prepares cookie too early 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: --- A consumer prepares its cookie at the moment its task is started (in do_syncrep1), then calls ldap_sync_search, but this is where we can figure out if there's another refresh running already and suspend the task. When that other refresh finishes and tells another one to resume, we just call ldap_sync_search so keep the old cookie rather than update it to match what we now know. This doesn't affect correctness but forces the other provider(s) to reiterate something the consumer already knows, this can be very expensive for both. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10430] New: Heap Buffer Overflow in parse_whsp causes Out-of-Bounds Read
by openldap-its＠openldap.org 09 Mar '26

09 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10430 Issue ID: 10430 Summary: Heap Buffer Overflow in parse_whsp causes Out-of-Bounds Read Product: OpenLDAP Version: unspecified Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: zesheng(a)tamu.edu Target Milestone: --- ## Summary A heap buffer overflow vulnerability in OpenLDAP's `parse_whsp()` function allows an attacker to trigger out-of-bounds memory reads when parsing malformed LDAP schema definitions, potentially leading to information disclosure or crashes. ## Root Cause The vulnerability exists in `libraries/libldap/schema.c` at line 1090. The `parse_whsp()` function iterates through a string checking for whitespace characters using `LDAP_SPACE()` macro, but does not verify that the pointer stays within the allocated buffer bounds. When parsing malformed schema strings that end unexpectedly, the function reads beyond the heap buffer. ### Vulnerable Code (schema.c:1086-1092) ```c /* Gobble optional whitespace */ static void parse_whsp(const char **sp) { while (LDAP_SPACE(**sp)) // BUG: no bounds check, can read past buffer (*sp)++; } ``` ### LDAP_SPACE Macro (ldap_pvt.h:255) ```c #define LDAP_SPACE(c) ((c) == ' ' || (c) == '\t' || (c) == '\n') ``` The macro checks for space/tab/newline but does NOT check for null terminator. If the heap memory immediately after the allocated buffer happens to contain whitespace bytes (0x20, 0x09, 0x0a), the function continues reading out of bounds. ## PoC ### Trigger file A crafted schema string (`poc`, 49 bytes) that triggers the overflow: ``` (13.5 NAME 'caseExactMatch' SYNTAX 'nooideithe1r. ``` ``` hexdump -C poc: 00000000 28 31 33 2e 35 20 4e 41 4d 45 20 27 63 61 73 65 |(13.5 NAME 'case| 00000010 45 78 61 63 74 4d 61 74 63 68 27 20 53 59 4e 54 |ExactMatch' SYNT| 00000020 41 58 20 27 6e 6f 6f 69 64 65 69 74 68 65 31 72 |AX 'nooideithe1r| 00000030 2e |.| ``` ### How to generate poc ```python # generate_poc.py data = b"(13.5 NAME 'caseExactMatch' SYNTAX 'nooideithe1r." with open("poc", "wb") as f: f.write(data) ``` --- ## Trigger Method 1: Direct API Call ```c // test_schema.c #include <stdio.h> #include <stdlib.h> #include <string.h> #include <ldap.h> #include <ldap_schema.h> int main(int argc, char **argv) { FILE *f = fopen("poc", "rb"); fseek(f, 0, SEEK_END); long size = ftell(f); fseek(f, 0, SEEK_SET); char *input = malloc(size + 1); fread(input, 1, size, f); input[size] = '\0'; fclose(f); int code = 0; const char *errp = NULL; // This triggers the vulnerability LDAPAttributeType *at = ldap_str2attributetype(input, &code, &errp, LDAP_SCHEMA_ALLOW_ALL); if (at) { ldap_attributetype_free(at); } free(input); return 0; } ``` **Build and run:** ```bash # Build OpenLDAP with AddressSanitizer cd openldap ./configure CC=clang CFLAGS="-fsanitize=address -g" --without-tls make # Compile and run test clang -fsanitize=address -g -I include \ -L libraries/libldap/.libs -L libraries/liblber/.libs \ test_schema.c -o test_schema -lldap -llber \ -Wl,-rpath,libraries/libldap/.libs:libraries/liblber/.libs ./test_schema ``` **Output:** ``` ==PID==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x506000000052 at pc 0x... bp 0x... sp 0x... READ of size 1 at 0x506000000052 thread T0 #0 0x... in parse_whsp libraries/libldap/schema.c:1090:9 #1 0x... in ldap_str2attributetype libraries/libldap/schema.c:2313:5 0x506000000052 is located 0 bytes after 50-byte region [0x506000000020,0x506000000052) allocated by thread T0 here: #0 0x... in malloc #1 0x... in main test_schema.c:... SUMMARY: AddressSanitizer: heap-buffer-overflow schema.c:1090:9 in parse_whsp ``` --- ## Trigger Method 2: Fuzzer ```c // fuzz_schema.c #include <stdint.h> #include <stddef.h> #include <stdlib.h> #include <string.h> #include <ldap.h> #include <ldap_schema.h> static const unsigned int flags[] = { LDAP_SCHEMA_ALLOW_NONE, LDAP_SCHEMA_ALLOW_NO_OID, LDAP_SCHEMA_ALLOW_QUOTED, LDAP_SCHEMA_ALLOW_DESCR, LDAP_SCHEMA_ALLOW_ALL, }; #define NUM_FLAGS (sizeof(flags) / sizeof(flags[0])) int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) { if (size == 0 || size > 16384) return 0; char *input = (char *)malloc(size + 1); if (!input) return 0; memcpy(input, data, size); input[size] = '\0'; int code = 0; const char *errp = NULL; // Test ldap_str2attributetype with different flags for (size_t i = 0; i < NUM_FLAGS; i++) { code = 0; errp = NULL; LDAPAttributeType *at = ldap_str2attributetype(input, &code, &errp, flags[i]); if (at) { ldap_attributetype_free(at); } } // Test ldap_str2objectclass for (size_t i = 0; i < NUM_FLAGS; i++) { code = 0; errp = NULL; LDAPObjectClass *oc = ldap_str2objectclass(input, &code, &errp, flags[i]); if (oc) { ldap_objectclass_free(oc); } } free(input); return 0; } ``` **Build and run:** ```bash clang -fsanitize=fuzzer,address -g -I include \ -L libraries/libldap/.libs -L libraries/liblber/.libs \ fuzz_schema.c -o fuzz_schema -lldap -llber \ -Wl,-rpath,libraries/libldap/.libs:libraries/liblber/.libs mkdir corpus && cp poc corpus/ ./fuzz_schema corpus/ ``` --- ## Impact | Aspect | Details | |--------|---------| | **Type** | Out-of-Bounds Read / Information Disclosure | | **Severity** | High | | **Attack Vector** | Malicious schema definition string | | **Affected Components** | `parse_whsp()`, `ldap_str2attributetype()`, `ldap_str2objectclass()`, libldap | | **Affected Applications** | Any application using libldap to parse LDAP schema definitions | | **CWE** | CWE-125 (Out-of-bounds Read) | --- ## Suggested Fix Add bounds checking in `parse_whsp()` to ensure it doesn't read past the null terminator: ```c static void parse_whsp(const char **sp) { while (**sp && LDAP_SPACE(**sp)) // Add null check (*sp)++; } ``` Note: `LDAP_SPACE('\0')` is false (0x00 is not space/tab/newline), so the issue only occurs when adjacent heap memory contains whitespace bytes. However, adding an explicit null check makes the code more robust and clearly documents the termination condition. -- You are receiving this mail because: You are on the CC list for the issue.

1 15

[Issue 10446] New: memory leak in authzPrettyNormal
by openldap-its＠openldap.org 09 Mar '26

09 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10446 Issue ID: 10446 Summary: memory leak in authzPrettyNormal Product: OpenLDAP Version: 2.6.12 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: kangyang126(a)gmail.com Target Milestone: --- # Memory Leak Fix Report: saslauthz.c ## Executive Summary A memory leak of 14 bytes per search operation was identified and fixed in the `authzPrettyNormal()` function. The leak occurred during LDAP search filter parsing when processing authorization values (authzDN/authzTo/authzFrom attributes). ## Issue Description ### Symptoms - LeakSanitizer detected a 14-byte memory leak per affected operation - Leak occurred during search operations with authorization filters - Memory allocated by `ldap_url_desc2str()` was never freed ### Detection ``` ==50210==ERROR: LeakSanitizer: detected memory leaks Direct leak of 14 byte(s) in 1 object(s) allocated from: #0 0x55d5617e1614 in malloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:67:3 #1 0x55d561dd5f04 in ber_memalloc_x /src/openldap/libraries/liblber/memory.c:228:9 #2 0x55d561d6f2ba in ldap_url_desc2str /src/openldap/libraries/libldap/url.c:803:6 #3 0x55d5619df587 in authzPrettyNormal /src/openldap/servers/slapd/saslauthz.c:843:23 #4 0x55d5619ddf5e in authzNormalize /src/openldap/servers/slapd/saslauthz.c:885:7 #5 0x55d561902b22 in asserted_value_validate_normalize /src/openldap/servers/slapd/value.c:170:8 #6 0x55d5618f8ac4 in get_ava /src/openldap/servers/slapd/ava.c:121:7 #7 0x55d5618688d0 in get_filter0 /src/openldap/servers/slapd/filter.c:151:9 #8 0x55d561872cc7 in get_filter_list /src/openldap/servers/slapd/filter.c:350:9 #9 0x55d561868595 in get_filter0 /src/openldap/servers/slapd/filter.c:231:9 #10 0x55d561872cc7 in get_filter_list /src/openldap/servers/slapd/filter.c:350:9 #11 0x55d561868595 in get_filter0 /src/openldap/servers/slapd/filter.c:231:9 #12 0x55d561872cc7 in get_filter_list /src/openldap/servers/slapd/filter.c:350:9 #13 0x55d561868595 in get_filter0 /src/openldap/servers/slapd/filter.c:231:9 #14 0x55d5618ad657 in do_search /src/openldap/servers/slapd/search.c:126:15 ``` ## Root Cause Analysis ### Memory Allocation Mismatch The issue stems from a mismatch between memory allocation strategies: 1. **Function Call Chain:** ``` get_ava() → asserted_value_validate_normalize() [with ctx=op->o_tmpmemctx] → authzNormalize() → authzPrettyNormal() → ldap_url_desc2str() ``` 2. **The Problem:** - `ldap_url_desc2str()` allocates memory using `LDAP_MALLOC()` (global heap) - The calling code expects memory allocated via `slap_sl_malloc(ctx)` (context-aware) - Context-aware memory is automatically freed when the operation completes - Global heap memory requires explicit `ber_memfree()` call - No explicit free was performed, causing the leak ### Code Location **File:** `servers/slapd/saslauthz.c` **Function:** `authzPrettyNormal()` **Lines:** 842-849 (original code) ```c // BEFORE (leaked memory): ludp->lud_port = 0; normalized->bv_val = ldap_url_desc2str( ludp ); // ← Allocates with LDAP_MALLOC if ( normalized->bv_val ) { normalized->bv_len = strlen( normalized->bv_val ); } else { rc = LDAP_INVALID_SYNTAX; } ``` ## Fix Implementation ### Solution Strategy Copy the result from `ldap_url_desc2str()` into context-allocated memory, then free the original allocation. ### Modified Code ```diff diff --git a/servers/slapd/saslauthz.c b/servers/slapd/saslauthz.c index 86ef944..1833921 100644 --- a/servers/slapd/saslauthz.c +++ b/servers/slapd/saslauthz.c @@ -840,12 +840,16 @@ is_dn: bv.bv_len = val->bv_len - ( bv.bv_val - val->bv_val ); } ludp->lud_port = 0; - normalized->bv_val = ldap_url_desc2str( ludp ); - if ( normalized->bv_val ) { - normalized->bv_len = strlen( normalized->bv_val ); - - } else { - rc = LDAP_INVALID_SYNTAX; + { + char *tmpstr = ldap_url_desc2str( ludp ); + if ( tmpstr ) { + normalized->bv_len = strlen( tmpstr ); + normalized->bv_val = slap_sl_malloc( normalized->bv_len + 1, ctx ); + strcpy( normalized->bv_val, tmpstr ); + ber_memfree( tmpstr ); + } else { + rc = LDAP_INVALID_SYNTAX; + } } done: ``` ### Fix Details 1. Store `ldap_url_desc2str()` result in temporary variable `tmpstr` 2. Allocate new memory using `slap_sl_malloc(ctx)` (context-aware allocator) 3. Copy the string content to the new memory 4. Free the original allocation using `ber_memfree()` 5. Result: `normalized->bv_val` now contains context-managed memory ## Impact Assessment ### Affected Operations - LDAP search operations with authorization filters - Filters containing authzDN, authzTo, or authzFrom attributes - Any operation using authz URL normalization ## Harness ``` #define _GNU_SOURCE /* For memfd_create */ #include "portable.h" #include <stdio.h> #include <string.h> #include <unistd.h> #include <fcntl.h> #include <sys/mman.h> #include <sys/types.h> #include <signal.h> #include "slap.h" /* 1. Fix function declarations to match return types in OpenLDAP source code */ extern void slap_sl_mem_init( void ); extern int slapd_daemon_init( const char *urls ); extern int extops_init( void ); /* Returns int */ extern void lutil_passwd_init( void ); extern int slap_init( int mode, const char *name ); extern int read_config( const char *fname, const char *dname ); extern int connections_init( void ); /* Returns int */ extern int slap_startup( Backend *be ); void slapd_daemon_nothread( void ) {} extern int ldap_pvt_thread_initialize( void ); /* Returns int */ extern void* ldap_pvt_thread_pool_context( void ); extern void* connection_read_thread( void *ctx, void *arg ); extern void connection_closing( Connection *c, const char *why ); extern int connection_resched( Connection *c ); extern Connection* connection_init( int sfd, Listener *l, const char *authid, const char *dns, int flags, slap_ssf_t ssf, struct berval *authid_out ); extern ldap_pvt_thread_pool_t connection_pool; static Listener *global_listener = NULL; static struct berval authid_bv = {0, ""}; int LLVMFuzzerInitialize(int *argc, char ***argv) { signal(SIGPIPE, SIG_IGN); slap_debug = 0; slap_sl_mem_init(); if ( 0 != slapd_daemon_init("ldapi://%2Ftmp%2Ffuzz.sock") ) return 1; extops_init(); lutil_passwd_init(); if ( slap_init(SLAP_SERVER_MODE, "slapd-fuzz") ) return 2; read_config( NULL, NULL ); connections_init(); slap_startup(NULL); slapd_daemon_nothread(); ldap_pvt_thread_initialize(); global_listener = slapd_get_listeners()[0]; if (!global_listener) return 3; return 0; } #include <sys/socket.h> int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size) { if (Size < 2 || Size > 65536) return 0; /* 2. Use socketpair to simulate socket read/write */ int sv[2]; if (socketpair(AF_UNIX, SOCK_STREAM, 0, sv) < 0) return 0; if (write(sv[0], Data, Size) != (ssize_t)Size) { close(sv[0]); close(sv[1]); return 0; } /* Close write end so server receives EOF after reading data */ close(sv[0]); /* 3. Create connection (server uses sv[1]) */ Connection *c = connection_init(sv[1], global_listener, "fuzz", "IP=127.0.0.1", 0, 0, &authid_bv); if (!c) { close(sv[1]); return 0; } void* ctx = ldap_pvt_thread_pool_context(); /* Execute parsing logic */ connection_read_thread(ctx, (void*)(long)sv[1]); /* Wait for thread pool to complete all tasks to prevent background threads from accessing freed connection */ int active = 0, pending = 0; do { ldap_pvt_thread_pool_query(&connection_pool, LDAP_PVT_THREAD_POOL_PARAM_PENDING, &pending); ldap_pvt_thread_pool_query(&connection_pool, LDAP_PVT_THREAD_POOL_PARAM_ACTIVE, &active); if (active == 0 && pending == 0) break; ldap_pvt_thread_yield(); } while (1); /* 4. Thoroughly clean up manually, avoiding unstable macros * Directly manipulate queue pointers to ensure no 'error: use of undeclared identifier o_next' */ Operation *op; while ((op = LDAP_STAILQ_FIRST(&c->c_ops)) != NULL) { LDAP_STAILQ_REMOVE_HEAD(&c->c_ops, o_next); LDAP_STAILQ_NEXT(op, o_next) = NULL; slap_op_free(op, ctx); } LDAP_STAILQ_INIT(&c->c_ops); /* Close and reclaim Connection memory */ connection_closing(c, "fuzz complete"); connection_resched(c); /* ldap_pvt_thread_pool_resume(&connection_pool); */ return 0; } ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10449] New: memory leak in parseReadAttrs
by openldap-its＠openldap.org 09 Mar '26

09 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10449 Issue ID: 10449 Summary: memory leak in parseReadAttrs Product: OpenLDAP Version: 2.6.12 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: kangyang126(a)gmail.com Target Milestone: --- # ASAN Leak Report: Pre-read / Post-read Control Attributes ## Component * **File:** `servers/slapd/controls.c` * **Function:** `parseReadAttrs` ## Issue Description **LeakSanitizer Error:** Memory leak detected in `AttributeName` array. ```plaintext ==202371==ERROR: LeakSanitizer: detected memory leaks Direct leak of 80 byte(s) in 1 object(s) allocated from: #0 0x555555963614 in malloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:67:3 #1 0x555555f578d4 in ber_memalloc_x /src/openldap/libraries/liblber/memory.c:228:9 #2 0x555555f4c5e2 in ber_get_stringbvl /src/openldap/libraries/liblber/decode.c:421:14 #3 0x555555f4ac2f in ber_scanf /src/openldap/libraries/liblber/decode.c:815:9 #4 0x555555b150e4 in parseReadAttrs /src/openldap/servers/slapd/controls.c:1514:7 #5 0x555555b0d13c in slap_parse_ctrl /src/openldap/servers/slapd/controls.c:738:10 #6 0x555555b0e101 in get_ctrls2 /src/openldap/servers/slapd/controls.c:929:16 #7 0x555555a35c0e in do_modrdn /src/openldap/servers/slapd/modrdn.c:129:6 #8 0x5555559e055d in connection_operation /src/openldap/servers/slapd/connection.c:1137:7 #9 0x5555559df327 in connection_read_thread /src/openldap/servers/slapd/connection.c:1289:14 #10 0x5555559a769a in LLVMFuzzerTestOneInput /src/fuzz_slapd.c:88:5 ``` The function `parseReadAttrs` uses `ber_scanf` with the `M` format specifier to allocate an array of `AttributeName` structures. 1. **Memory Leak:** This array was not freed if the function encountered an error (e.g., critical control verification failure) after the allocation. 2. **Invalid Free:** Attempting to free `bv_val` strings inside the array caused an "attempting free on address which was not malloc()-ed" error, because these pointers refer to the internal `BerElement` buffer. 3. **Segmentation Fault:** Accessing the array to write a terminator without checking for `NULL` caused a crash on empty attribute lists. ## Fix * **Leak Fix:** Added comprehensive cleanup logic at the `done` label to free the `AttributeName` array if an error occurs. * **Logic Fix:** Refactored the loop to filter attributes without attempting to free the internal string pointers, avoiding the `Invalid Free` error. ## Diff ```diff diff --git a/servers/slapd/controls.c b/servers/slapd/controls.c index 3d18345..3c90884 100644 --- a/servers/slapd/controls.c +++ b/servers/slapd/controls.c @@ -1476,7 +1476,7 @@ parseReadAttrs( LDAPControl *ctrl, int post ) { - ber_len_t siz, off, i; + ber_len_t siz, off, i, good_i = 0; BerElement *ber; AttributeName *an = NULL; @@ -1520,14 +1520,16 @@ parseReadAttrs( for ( i = 0; i < siz; i++ ) { const char *dummy = NULL; int rc; + struct berval name = an[i].an_name; an[i].an_desc = NULL; an[i].an_oc = NULL; an[i].an_flags = 0; - rc = slap_bv2ad( &an[i].an_name, &an[i].an_desc, &dummy ); + rc = slap_bv2ad( &name, &an[i].an_desc, &dummy ); if ( rc == LDAP_SUCCESS ) { - an[i].an_name = an[i].an_desc->ad_cname; - + an[good_i] = an[i]; + an[good_i].an_name = an[good_i].an_desc->ad_cname; + good_i++; } else { int j; static struct berval special_attrs[] = { @@ -1537,23 +1539,29 @@ parseReadAttrs( BER_BVNULL }; - /* deal with special attribute types */ for ( j = 0; !BER_BVISNULL( &special_attrs[ j ] ); j++ ) { - if ( bvmatch( &an[i].an_name, &special_attrs[ j ] ) ) { - an[i].an_name = special_attrs[ j ]; + if ( bvmatch( &name, &special_attrs[ j ] ) ) { + an[good_i] = an[i]; + an[good_i].an_name = special_attrs[ j ]; + good_i++; break; } } - if ( BER_BVISNULL( &special_attrs[ j ] ) && ctrl->ldctl_iscritical ) { - rs->sr_err = rc; - rs->sr_text = dummy ? dummy - : READMSG( post, "unknown attributeType" ); - goto done; + if ( BER_BVISNULL( &special_attrs[ j ] ) ) { + if ( ctrl->ldctl_iscritical ) { + rs->sr_err = rc; + rs->sr_text = dummy ? dummy + : READMSG( post, "unknown attributeType" ); + goto done; + } } } } + if ( an ) + BER_BVZERO( &an[good_i].an_name ); + if ( post ) { op->o_postread_attrs = an; op->o_postread = ctrl->ldctl_iscritical @@ -1568,6 +1576,9 @@ parseReadAttrs( done: (void) ber_free( ber, 1 ); + if ( rs->sr_err != LDAP_SUCCESS && an ) { + ber_memfree( an ); + } return rs->sr_err; } ``` ## Harness ``` #define _GNU_SOURCE /* For memfd_create */ #include "portable.h" #include <stdio.h> #include <string.h> #include <unistd.h> #include <fcntl.h> #include <sys/mman.h> #include <sys/types.h> #include <signal.h> #include "slap.h" /* 1. Fix function declarations to match return types in OpenLDAP source code */ extern void slap_sl_mem_init( void ); extern int slapd_daemon_init( const char *urls ); extern int extops_init( void ); /* Returns int */ extern void lutil_passwd_init( void ); extern int slap_init( int mode, const char *name ); extern int read_config( const char *fname, const char *dname ); extern int connections_init( void ); /* Returns int */ extern int slap_startup( Backend *be ); void slapd_daemon_nothread( void ) {} extern int ldap_pvt_thread_initialize( void ); /* Returns int */ extern void* ldap_pvt_thread_pool_context( void ); extern void* connection_read_thread( void *ctx, void *arg ); extern void connection_closing( Connection *c, const char *why ); extern int connection_resched( Connection *c ); extern Connection* connection_init( int sfd, Listener *l, const char *authid, const char *dns, int flags, slap_ssf_t ssf, struct berval *authid_out ); extern ldap_pvt_thread_pool_t connection_pool; static Listener *global_listener = NULL; static struct berval authid_bv = {0, ""}; int LLVMFuzzerInitialize(int *argc, char ***argv) { signal(SIGPIPE, SIG_IGN); slap_debug = 0; slap_sl_mem_init(); if ( 0 != slapd_daemon_init("ldapi://%2Ftmp%2Ffuzz.sock") ) return 1; extops_init(); lutil_passwd_init(); if ( slap_init(SLAP_SERVER_MODE, "slapd-fuzz") ) return 2; read_config( NULL, NULL ); connections_init(); slap_startup(NULL); slapd_daemon_nothread(); ldap_pvt_thread_initialize(); global_listener = slapd_get_listeners()[0]; if (!global_listener) return 3; return 0; } #include <sys/socket.h> int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size) { if (Size < 2 || Size > 65536) return 0; /* 2. Use socketpair to simulate socket read/write */ int sv[2]; if (socketpair(AF_UNIX, SOCK_STREAM, 0, sv) < 0) return 0; if (write(sv[0], Data, Size) != (ssize_t)Size) { close(sv[0]); close(sv[1]); return 0; } /* Close write end so server receives EOF after reading data */ close(sv[0]); /* 3. Create connection (server uses sv[1]) */ Connection *c = connection_init(sv[1], global_listener, "fuzz", "IP=127.0.0.1", 0, 0, &authid_bv); if (!c) { close(sv[1]); return 0; } void* ctx = ldap_pvt_thread_pool_context(); /* Execute parsing logic */ connection_read_thread(ctx, (void*)(long)sv[1]); /* Wait for thread pool to complete all tasks to prevent background threads from accessing freed connection */ int active = 0, pending = 0; do { ldap_pvt_thread_pool_query(&connection_pool, LDAP_PVT_THREAD_POOL_PARAM_PENDING, &pending); ldap_pvt_thread_pool_query(&connection_pool, LDAP_PVT_THREAD_POOL_PARAM_ACTIVE, &active); if (active == 0 && pending == 0) break; ldap_pvt_thread_yield(); } while (1); /* 4. Thoroughly clean up manually, avoiding unstable macros * Directly manipulate queue pointers to ensure no 'error: use of undeclared identifier o_next' */ Operation *op; while ((op = LDAP_STAILQ_FIRST(&c->c_ops)) != NULL) { LDAP_STAILQ_REMOVE_HEAD(&c->c_ops, o_next); LDAP_STAILQ_NEXT(op, o_next) = NULL; slap_op_free(op, ctx); } LDAP_STAILQ_INIT(&c->c_ops); /* Close and reclaim Connection memory */ connection_closing(c, "fuzz complete"); connection_resched(c); /* ldap_pvt_thread_pool_resume(&connection_pool); */ return 0; } ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10425] back-asyncmeta: suffixmassage empty target underflows dn length in asyncmeta_dn_massage
by openldap-its＠openldap.org 09 Mar '26

09 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10425 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 10448] New: Memory leak in syncprov_parseCtrl
by openldap-its＠openldap.org 09 Mar '26

09 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10448 Issue ID: 10448 Summary: Memory leak in syncprov_parseCtrl 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: kangyang126(a)gmail.com Target Milestone: --- # ASAN Leak Report: Sync Provider Control ## Component * **File:** `servers/slapd/overlays/syncprov.c` * **Function:** `syncprov_parseCtrl` ## Issue Description **LeakSanitizer Error:** Memory leak of `sync_control` structure. ```plaintext ==266290==ERROR: LeakSanitizer: detected memory leaks Direct leak of 80 byte(s) in 1 object(s) allocated from: #0 0x555555964614 in malloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:67:3 #1 0x555555f58a04 in ber_memalloc_x /src/openldap/libraries/liblber/memory.c:228:9 #2 0x555555a7cb06 in ch_malloc /src/openldap/servers/slapd/ch_malloc.c:54:23 #3 0x555555b3ba6c in slap_sl_calloc /src/openldap/servers/slapd/sl_malloc.c:401:12 #4 0x555555ca1734 in syncprov_parseCtrl /src/openldap/servers/slapd/overlays/syncprov.c:4333:7 #5 0x555555b0e13c in slap_parse_ctrl /src/openldap/servers/slapd/controls.c:738:10 #6 0x555555b0f101 in get_ctrls2 /src/openldap/servers/slapd/controls.c:929:16 #7 0x555555a30eae in do_search /src/openldap/servers/slapd/search.c:194:6 #8 0x5555559e155d in connection_operation /src/openldap/servers/slapd/connection.c:1137:7 #9 0x5555559e0327 in connection_read_thread /src/openldap/servers/slapd/connection.c:1289:14 #10 0x5555559a869a in LLVMFuzzerTestOneInput /src/fuzz_slapd.c:88:5 ``` The `syncprov` overlay allocates a specific `sync_control` structure and attaches it to the operation's control list (`op->o_controls`) when parsing the `LDAP_CONTROL_SYNC`. * **Leak:** The core server's cleanup routine (`slap_free_ctrls`) is unaware of this overlay-specific structure. If the operation is abandoned or fails (e.g., during parsing of subsequent controls), the `sync_control` and its internal allocations (context CSNs, session IDs) are never freed. ## Fix * **Cleanup Callback:** Defined a new callback function `syncprov_ctrl_cleanup` that properly frees the `sync_control` structure. * **Registration:** Updated `syncprov_parseCtrl` to register this callback (`op->o_callback`) immediately after allocating the control. This ensures `slap_cleanup_play` invokes the cleanup routine during operation teardown, preventing the leak. ## Diff ```diff diff --git a/servers/slapd/overlays/syncprov.c b/servers/slapd/overlays/syncprov.c index 042d742..7257f79 100644 --- a/servers/slapd/overlays/syncprov.c +++ b/servers/slapd/overlays/syncprov.c @@ -4246,6 +4246,26 @@ syncprov_db_destroy( return 0; } +static int +syncprov_ctrl_cleanup( Operation *op, SlapReply *rs ) +{ + if ( op->o_controls[slap_cids.sc_LDAPsync] ) { + sync_control *sr = op->o_controls[slap_cids.sc_LDAPsync]; + op->o_controls[slap_cids.sc_LDAPsync] = NULL; + if ( sr->sr_state.ctxcsn ) { + ber_bvarray_free_x( sr->sr_state.ctxcsn, op->o_tmpmemctx ); + } + if ( sr->sr_state.sids ) { + op->o_tmpfree( sr->sr_state.sids, op->o_tmpmemctx ); + } + if ( sr->sr_state.octet_str.bv_val ) { + op->o_tmpfree( sr->sr_state.octet_str.bv_val, op->o_tmpmemctx ); + } + op->o_tmpfree( sr, op->o_tmpmemctx ); + } + return slap_freeself_cb( op, rs ); +} + static int syncprov_parseCtrl ( Operation *op, SlapReply *rs, @@ -4353,6 +4373,13 @@ static int syncprov_parseCtrl ( op->o_sync_mode |= mode; /* o_sync_mode shares o_sync */ + { + slap_callback *cb = op->o_tmpcalloc( 1, sizeof(slap_callback), op->o_tmpmemctx ); + cb->sc_cleanup = syncprov_ctrl_cleanup; + cb->sc_next = op->o_callback; + op->o_callback = cb; + } + return LDAP_SUCCESS; } ``` ## Harness ``` #define _GNU_SOURCE /* For memfd_create */ #include "portable.h" #include <stdio.h> #include <string.h> #include <unistd.h> #include <fcntl.h> #include <sys/mman.h> #include <sys/types.h> #include <signal.h> #include "slap.h" /* 1. Fix function declarations to match return types in OpenLDAP source code */ extern void slap_sl_mem_init( void ); extern int slapd_daemon_init( const char *urls ); extern int extops_init( void ); /* Returns int */ extern void lutil_passwd_init( void ); extern int slap_init( int mode, const char *name ); extern int read_config( const char *fname, const char *dname ); extern int connections_init( void ); /* Returns int */ extern int slap_startup( Backend *be ); void slapd_daemon_nothread( void ) {} extern int ldap_pvt_thread_initialize( void ); /* Returns int */ extern void* ldap_pvt_thread_pool_context( void ); extern void* connection_read_thread( void *ctx, void *arg ); extern void connection_closing( Connection *c, const char *why ); extern int connection_resched( Connection *c ); extern Connection* connection_init( int sfd, Listener *l, const char *authid, const char *dns, int flags, slap_ssf_t ssf, struct berval *authid_out ); extern ldap_pvt_thread_pool_t connection_pool; static Listener *global_listener = NULL; static struct berval authid_bv = {0, ""}; int LLVMFuzzerInitialize(int *argc, char ***argv) { signal(SIGPIPE, SIG_IGN); slap_debug = 0; slap_sl_mem_init(); if ( 0 != slapd_daemon_init("ldapi://%2Ftmp%2Ffuzz.sock") ) return 1; extops_init(); lutil_passwd_init(); if ( slap_init(SLAP_SERVER_MODE, "slapd-fuzz") ) return 2; read_config( NULL, NULL ); connections_init(); slap_startup(NULL); slapd_daemon_nothread(); ldap_pvt_thread_initialize(); global_listener = slapd_get_listeners()[0]; if (!global_listener) return 3; return 0; } #include <sys/socket.h> int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size) { if (Size < 2 || Size > 65536) return 0; /* 2. Use socketpair to simulate socket read/write */ int sv[2]; if (socketpair(AF_UNIX, SOCK_STREAM, 0, sv) < 0) return 0; if (write(sv[0], Data, Size) != (ssize_t)Size) { close(sv[0]); close(sv[1]); return 0; } /* Close write end so server receives EOF after reading data */ close(sv[0]); /* 3. Create connection (server uses sv[1]) */ Connection *c = connection_init(sv[1], global_listener, "fuzz", "IP=127.0.0.1", 0, 0, &authid_bv); if (!c) { close(sv[1]); return 0; } void* ctx = ldap_pvt_thread_pool_context(); /* Execute parsing logic */ connection_read_thread(ctx, (void*)(long)sv[1]); /* Wait for thread pool to complete all tasks to prevent background threads from accessing freed connection */ int active = 0, pending = 0; do { ldap_pvt_thread_pool_query(&connection_pool, LDAP_PVT_THREAD_POOL_PARAM_PENDING, &pending); ldap_pvt_thread_pool_query(&connection_pool, LDAP_PVT_THREAD_POOL_PARAM_ACTIVE, &active); if (active == 0 && pending == 0) break; ldap_pvt_thread_yield(); } while (1); /* 4. Thoroughly clean up manually, avoiding unstable macros * Directly manipulate queue pointers to ensure no 'error: use of undeclared identifier o_next' */ Operation *op; while ((op = LDAP_STAILQ_FIRST(&c->c_ops)) != NULL) { LDAP_STAILQ_REMOVE_HEAD(&c->c_ops, o_next); LDAP_STAILQ_NEXT(op, o_next) = NULL; slap_op_free(op, ctx); } LDAP_STAILQ_INIT(&c->c_ops); /* Close and reclaim Connection memory */ connection_closing(c, "fuzz complete"); connection_resched(c); /* ldap_pvt_thread_pool_resume(&connection_pool); */ return 0; } ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10443] slap_sasl_mechs Heap Buffer Overflow due to race condition
by openldap-its＠openldap.org 09 Mar '26

09 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10443 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 10425] back-asyncmeta: suffixmassage empty target underflows dn length in asyncmeta_dn_massage
by openldap-its＠openldap.org 09 Mar '26

09 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10425 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 10307] New: Regression when searching for nonexistent entries and no access to DB
by openldap-its＠openldap.org 05 Mar '26

05 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10307 Issue ID: 10307 Summary: Regression when searching for nonexistent entries and no access to DB Product: OpenLDAP Version: 2.5.17 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: --- Patch incoming -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10293] New: Log operations generated by syncrepl at STATS level
by openldap-its＠openldap.org 02 Mar '26

02 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10293 Issue ID: 10293 Summary: Log operations generated by syncrepl at STATS level Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- Similarly to how incoming operations are logged, operations created by syncrepl should be logged as well. -- You are receiving this mail because: You are on the CC list for the issue.

1 16

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs