openldap-bugs February 2026

openldap-bugs@openldap.org

1 participants
52 discussions

[Issue 10363] New: Implement a target connection time-to-live in asyncmeta
by openldap-its＠openldap.org 13 Mar '26

13 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10363 Issue ID: 10363 Summary: Implement a target connection time-to-live in asyncmeta Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- Implement a feature that limits the maximum time before a target connection is reset, even if it is not idle - conn-ttl. To avoid too many target connections timing out at once, a minimum reset interval per target should also be configurable. So, a configuration of: conn-ttl 5s 5s would mean connections have a 5 seconds time-to-live, but a connection should be reset no more frequently that once every 5 seconds per target. This feature was requested by a customer. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10364] New: back-asyncmeta should process a notice-of-disconnect and close the target connection
by openldap-its＠openldap.org 13 Mar '26

13 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10364 Issue ID: 10364 Summary: back-asyncmeta should process a notice-of-disconnect and close the target connection Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- At present, back-asyncmeta discards all unsolicited messages, received on the target connections. It should instead process Notice-of-Disconnection messages and close the connections on which they were received. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10456] New: Record time it took to run purge task
by openldap-its＠openldap.org 13 Mar '26

13 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10456 Issue ID: 10456 Summary: Record time it took to run purge task Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- accesslog could report a summary at the end of the purge saying how long it took and how many entries were (or would have been if shutting down) removed in that run. Thinking SYNC level as that's where most accesslog's messages go already. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10395] New: Support multiple readers on uncommitted changes
by openldap-its＠openldap.org 13 Mar '26

13 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10395 Issue ID: 10395 Summary: Support multiple readers on uncommitted changes Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: renault.cle(a)gmail.com Target Milestone: --- Created attachment 1086 --> https://bugs.openldap.org/attachment.cgi?id=1086&action=edit A patch to support multiple readers on uncommitted changes Hello, The attached patch is not meant to be merged immediately into LMDB. Still, it demonstrates how I added a helpful feature to the key-value store: reading uncommitted changes from multiple transactions. I am conscious that the patch still requires some work and uses non-C99 features, i.e., atomics are C11, which could be a blocker for it to be merged upstream. I would also be delighted to merge these changes under a flag/define to ensure we don't impact other users with non-C99 stuff. The main feature we need at Meilisearch is to read uncommitted changes from multiple threads, compute parallel post-processing of different data structures [1], and speed up the search requests. We could have done the post-processing in a following transaction by opening multiple read transactions, but this would mean that the post-processed data structure would not include newly inserted or modified document IDs. Both data structures would be desync. Regarding the design choice, I decided to follow the same design as the nested write transactions: use the parent argument of the mdb_txn_begin [2], and allow the MDB_RDONLY flag, which was disallowed when the parent argument was non-NULL [3]. I find it clear enough that, by calling the mdb_txn_begin function with these arguments, you can call it multiple times (I need to update the doc) to obtain nested read-only transactions from the parent write transaction. ret = mdb_txn_begin(env, parent_txn, MDB_RDONLY, new_nested_rtxn); Note that this early proposal lacks security and error handling. The generated transactions are fake-read-only and actually write transactions that share the underlying parent allocations and data structures. This is unsafe and must be changed or reviewed carefully, but most importantly, we need to add read-only capabilities to these transactions to disallow writes. Using a Rust wrapper on top of LMDB, I wrapped the fake read-only transactions into ReadTxn, which disallows any writes at compile time. However, I haven't checked the conflict database creations or openings. The main issues I encountered were concurrent free of the main shared data structures when the different threads owning the transactions were dropping the transactions simultaneously. So, I decided to implement the equivalent of an ARC to free resources only when the last nested transaction was freed. I can share numbers about how this feature improves the post-processing by 4x-9x or from 1200s to 120s [1]. You can look at this PR, which I would be happy to merge once an improved version of this patch lands on LMDB upstream. I would be very happy if you could guide me a bit on how I could improve this patch to make it mergeable into LMDB. We want to contribute useful features like this to LMDB and not keep a deviant fork. LMDB works great; we are happy about it, and its performance is predictable. Have a lovely week, kero [1]: https://github.com/meilisearch/meilisearch/pull/5307 [2]: https://github.com/LMDB/lmdb/blob/14d6629bc8a9fe40d8a6bee1bf71c45afe7576b6/… [3]: https://github.com/LMDB/lmdb/blob/14d6629bc8a9fe40d8a6bee1bf71c45afe7576b6/… -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 10424] New: When using more than one syncrepl directive on a single DB, the contextCSN should be stored accordingly to the replication base
by openldap-its＠openldap.org 10 Mar '26

10 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10424 Issue ID: 10424 Summary: When using more than one syncrepl directive on a single DB, the contextCSN should be stored accordingly to the replication base Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: elecharny(a)apache.org Target Milestone: --- Trying to replicate cn=config but parially, I tried to set many syncrepl directives so that each oe of them just replicate the single element it is configured for. Here is an exemple thet replicate the frontend database and only it: {0}rid=004 provider=ldaps://openldap1:10636 bindmethod=simple binddn="cn=syncrepl,ou=accounts,dc=worteks,dc=com" credentials=blah tls_cacert=/opt/application/openldap/ssl/ca.crt tls_cert=/opt/application/openldap/ssl/openldap-common.crt tls_key=/opt/application/openldap/ssl/openldap-common.key tls_reqcert=demand tls_protocol_min=3.3 searchbase="olcDatabase={-1}frontend,cn=config" scope="base" type=refreshAndPersist retry="30 +" timeout=1 schemachecking=off If I have this single syncrepl directive, all is ok, it replicates the frontend data and only this entry. Would I like to replicate, says, 'cn=config' with another syncrepl directive like: olcSyncrepl: {0}rid=001 provider=ldaps://openldap1:10636 bindmethod=simple binddn="cn=syncrepl,ou=accounts,dc=worteks,dc=com" credentials=blah tls_cacert=/opt/application/openldap/ssl/ca.crt tls_cert=/opt/application/openldap/ssl/openldap-common.crt tls_key=/opt/application/openldap/ssl/openldap-common.key tls_reqcert=demand tls_protocol_min=3.3 searchbase="cn=config" scope="base" type=refreshAndPersist retry="30 +" timeout=1 schemachecking=off where the search base is different, then suddenly I get some 'CSN too old' errors, which make totally sense as we only have one single contextCSN stored in the root entry (cn=config in my use case). I know I'm really border line here (and the rational is that I want a partial replication of cn=config because the two servers are a bit different), but I would suggest that the contextCSN to be stored in the entry associated to the searchBase, not at the root of the database. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[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 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 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 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 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2026