- openldap-bugs - openldap.org

[Issue 10450] New: memory leak in parseAssert
by openldap-its＠openldap.org 07 Feb '26

07 Feb '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 4

[Issue 10448] New: Memory leak in syncprov_parseCtrl
by openldap-its＠openldap.org 06 Feb '26

06 Feb '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 4

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

06 Feb '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 3

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

06 Feb '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 2

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

06 Feb '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 2

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

06 Feb '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 1

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

06 Feb '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 8

[Issue 6104] race condition with cancel operation
by openldap-its＠openldap.org 06 Feb '26

06 Feb '26

https://bugs.openldap.org/show_bug.cgi?id=6104 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kangyang126(a)gmail.com --- Comment #16 from Howard Chu <hyc(a)openldap.org> --- *** Issue 10444 has been marked as a duplicate of this issue. *** -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6104] race condition with cancel operation
by openldap-its＠openldap.org 06 Feb '26

06 Feb '26

https://bugs.openldap.org/show_bug.cgi?id=6104 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=10444 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

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

06 Feb '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 1

[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 05 Feb '26

05 Feb '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 2

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

04 Feb '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 10

[Issue 10358] New: syncrepl can revert an entry's CSN
by openldap-its＠openldap.org 04 Feb '26

04 Feb '26

https://bugs.openldap.org/show_bug.cgi?id=10358 Issue ID: 10358 Summary: syncrepl can revert an entry's CSN 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 1080 --> https://bugs.openldap.org/attachment.cgi?id=1080&action=edit Debug log of an instance of this happening There is a sequence of operations which can force a MPR node to apply changes out of order (essentially reverting an operation). Currently investigating which part of the code that should have prevented this has let it slip. A sample log showing how this happened is attached. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 6916] slapo-unique returns operations error when assertion control is used
by openldap-its＠openldap.org 04 Feb '26

04 Feb '26

https://bugs.openldap.org/show_bug.cgi?id=6916 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=10440 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10437] New: Let service manager know when we're about to pause
by openldap-its＠openldap.org 03 Feb '26

03 Feb '26

https://bugs.openldap.org/show_bug.cgi?id=10437 Issue ID: 10437 Summary: Let service manager know when we're about to pause 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: --- Entering a pause and waiting for a task (back-ldap result, ...) to finish looks exactly the same as slapd hanging, even cn=monitor will stop responding. If the sysadmin has systemd or another manager that we can tell this is about to happen, we might as well try. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10436] New: Assorted fixes for 2.7
by openldap-its＠openldap.org 03 Feb '26

03 Feb '26

https://bugs.openldap.org/show_bug.cgi?id=10436 Issue ID: 10436 Summary: Assorted fixes for 2.7 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: --- Minor cleanups for unitialised variables, typos and annoying compiler warnings. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10439] New: The value of the mc_xcursor pointer in the context of calling the mdb_xcursor_init1() function
by openldap-its＠openldap.org 03 Feb '26

03 Feb '26

https://bugs.openldap.org/show_bug.cgi?id=10439 Issue ID: 10439 Summary: The value of the mc_xcursor pointer in the context of calling the mdb_xcursor_init1() function Product: OpenLDAP Version: 2.6.12 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: mishtitov(a)gmail.com Target Milestone: --- Problem occurs in functions `mdb_cursor_first()`, `mdb_cursor_last()` and `mdb_cursor_set()`. After having been compared to a NULL value, pointer 'mc->mc_xcursor' is passed in call to function 'mdb_xcursor_init1()` where it is dereferenced. This might happen when the node flag `F_DUPDATA` is set, but the database does not have the `MDB_DUPSORT` flag, leading to `mc->mc_xcursor` being uninitialized. I think that this is very unlikely to happen, but I haven't found a clear connection between the `F_DUPDATA` and `MDB_DUPSORT` flags. Please consider wheter if it's worth adding a NULL check there. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10438] New: Potential Dereference of NULL in ber_bvreplace_x
by openldap-its＠openldap.org 02 Feb '26

02 Feb '26

https://bugs.openldap.org/show_bug.cgi?id=10438 Issue ID: 10438 Summary: Potential Dereference of NULL in ber_bvreplace_x Product: OpenLDAP Version: 2.6.12 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: mishtitov(a)gmail.com Target Milestone: --- Return value of a function `ber_memrealloc_x` is dereferenced at [memory.c:711](https://git.openldap.org/openldap/openldap/-/blob/master/libr… withouth checking for NULL, but it is usually checked for this function. Notice that `ber_memrealloc_x()` might return NULL when `realloc()` fails. PLease consider adding a NULL check. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10431] New: Stack Buffer Underflow in ldif_read_record causes Out-of-Bounds Read
by openldap-its＠openldap.org 30 Jan '26

30 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10431 Issue ID: 10431 Summary: Stack Buffer Underflow in ldif_read_record 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 stack buffer underflow vulnerability in OpenLDAP's `ldif_read_record()` function allows an attacker to trigger out-of-bounds memory reads when processing malformed LDIF data, potentially leading to information disclosure or crashes. ## Root Cause The vulnerability exists in `libraries/libldap/ldif.c` at line 803. When `fgets()` returns NULL and sets `len = 0`, the loop increment expression `last_ch = line[len-1]` accesses `line[-1]`, causing a stack buffer underflow. ### Vulnerable Code (ldif.c:799-803) ```c int ldif_read_record( LDIFFP *lfp, unsigned long *lno, char **bufp, int *buflenp ) { char line[LDIF_MAXLINE], *nbufp; // line buffer starts at offset 32 ber_len_t lcur = 0, len; int last_ch = '\n', found_entry = 0, stop, top_comment = 0; for ( stop = 0; !stop; last_ch = line[len-1] ) { // BUG: when len=0, accesses line[-1] // ... if ( fgets( line, sizeof( line ), lfp->fp ) == NULL ) { // ... stop = 1; len = 0; // len is set to 0 here } // ... } // At loop increment: line[len-1] = line[-1] = UNDERFLOW! } ``` ## PoC ### Trigger file A crafted LDIF file (`poc`, 27 bytes) that triggers the underflow: ``` hexdump -C poc: 00000000 00 00 00 00 01 00 00 00 64 74 65 21 73 74 2c 64 |........dte!st,d| 00000010 63 3d ff 65 78 64 63 73 74 77 6f |c=.exdcstwo| ``` ### How to generate poc ```python # generate_poc.py data = bytes([ 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x64, 0x74, 0x65, 0x21, 0x73, 0x74, 0x2c, 0x64, 0x63, 0x3d, 0xff, 0x65, 0x78, 0x64, 0x63, 0x73, 0x74, 0x77, 0x6f ]) with open("poc", "wb") as f: f.write(data) ``` --- ## Trigger Method 1: Direct API Call ```c // test_ldif.c #include <stdio.h> #include <stdlib.h> #include <string.h> #include <ldap.h> #include <ldif.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); LDIFFP *fp = ldif_open_mem(input, size, "r"); if (fp) { unsigned long lineno = 0; char *buf = NULL; int buflen = 0; // This triggers the vulnerability ldif_read_record(fp, &lineno, &buf, &buflen); if (buf) ber_memfree(buf); ldif_close(fp); } 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_ldif.c -o test_ldif -lldap -llber \ -Wl,-rpath,libraries/libldap/.libs:libraries/liblber/.libs ./test_ldif ``` **Output:** ``` ==PID==ERROR: AddressSanitizer: stack-buffer-underflow on address 0x7fff... at pc 0x... bp 0x... sp 0x... READ of size 1 at 0x7fff... thread T0 #0 0x... in ldif_read_record libraries/libldap/ldif.c:803:37 Address 0x7fff... is located in stack of thread T0 at offset 31 in frame #0 0x... in ldif_read_record libraries/libldap/ldif.c:798 This frame has 1 object(s): [32, 4128) 'line' (line 799) <== Memory access at offset 31 underflows this variable SUMMARY: AddressSanitizer: stack-buffer-underflow ldif.c:803:37 in ldif_read_record ``` --- ## Trigger Method 2: Fuzzer ```c // fuzz_ldif.c #include <stdint.h> #include <stddef.h> #include <stdlib.h> #include <string.h> #include <ldap.h> #include <ldif.h> int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) { if (size == 0 || size > 65536) return 0; char *input = (char *)malloc(size + 1); if (!input) return 0; memcpy(input, data, size); input[size] = '\0'; char *mem_copy = (char *)malloc(size + 1); if (mem_copy) { memcpy(mem_copy, data, size); mem_copy[size] = '\0'; LDIFFP *fp = ldif_open_mem(mem_copy, size, "r"); if (fp) { unsigned long lineno = 0; char *buf = NULL; int buflen = 0; int count = 0; while (count < 100) { int rc = ldif_read_record(fp, &lineno, &buf, &buflen); if (rc <= 0) break; count++; } if (buf) ber_memfree(buf); ldif_close(fp); } free(mem_copy); } free(input); return 0; } ``` **Build and run:** ```bash clang -fsanitize=fuzzer,address -g -I include \ -L libraries/libldap/.libs -L libraries/liblber/.libs \ fuzz_ldif.c -o fuzz_ldif -lldap -llber \ -Wl,-rpath,libraries/libldap/.libs:libraries/liblber/.libs mkdir corpus && cp poc corpus/ ./fuzz_ldif corpus/ ``` --- ## Impact | Aspect | Details | |--------|---------| | **Type** | Out-of-Bounds Read / Information Disclosure | | **Severity** | High | | **Attack Vector** | Malicious LDIF file | | **Affected Components** | `ldif_read_record()`, libldap | | **Affected Applications** | Any application using libldap to parse LDIF (slapadd, ldapmodify, custom apps) | | **CWE** | CWE-124 (Buffer Underwrite / Buffer Underflow) | --- ## Suggested Fix Add a check to ensure `len > 0` before accessing `line[len-1]`: ```c for ( stop = 0; !stop; ) { // ... existing code ... // At end of loop body, before continuing: if (len > 0) { last_ch = line[len-1]; } // Or move len=0 case handling before the loop increment } ``` Alternative fix - initialize `len` to a safe value and guard the access: ```c for ( stop = 0; !stop; last_ch = (len > 0) ? line[len-1] : '\n' ) { ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10434] New: mdb.c error: use of undeclared identifier 'fd' in 0.9.34?
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10434 Issue ID: 10434 Summary: mdb.c error: use of undeclared identifier 'fd' in 0.9.34? Product: LMDB Version: unspecified Hardware: aarch64 OS: Mac OS Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: artkiver(a)gmail.com Target Milestone: --- Hi! I may be jumping the gun a bit, but noticed via repology.org that some distros had updated to LMDB 0.9.34 though I acknowledge the tagged commit reads: " 03d56d53 · Prep for release (0.9.34) · 2 days ago " From: https://gitlab.com/openldap/openldap/-/tags/LMDB_0.9.34 Regardless, I thought I would download the tarball and give it a whirl? For reference I am using macOS, more specifically: macOS 26.2 25C56 arm64 Command Line Tools 26.2.0.0.1.1764812424 Alas, I encountered the following errors when I attempted to build it: % make gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -c mdb.c mdb.c:2589:33: error: use of undeclared identifier 'fd' 2589 | else if (flags == MS_SYNC && MDB_FDATASYNC(env->me_fd)) | ^ mdb.c:132:32: note: expanded from macro 'MDB_FDATASYNC' 132 | # define MDB_FDATASYNC fcntl(fd, F_FULLFSYNC) | ^ mdb.c:2599:8: error: use of undeclared identifier 'fd' 2599 | if (MDB_FDATASYNC(env->me_fd)) | ^ mdb.c:132:32: note: expanded from macro 'MDB_FDATASYNC' 132 | # define MDB_FDATASYNC fcntl(fd, F_FULLFSYNC) | ^ 2 errors generated. make: *** [mdb.o] Error 1 A little bit more longwinded version (of basically the same error, though using MacPorts as it is my intention to update the Portfile for that project once it's functioning correctly) I've documented within MacPorts here, mentioning it more for reference: https://trac.macports.org/ticket/73204#comment:3 My apologies in advance if I am being too eager and 0.9.34 isn't officially released yet! Perhaps this is already known and planned to be fixed. I hope I'm not wasting anyone's time or attention erroneously. Thanks! -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10429] NULL Pointer Dereference in ldifutil.c
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

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

1 0

[Issue 10429] NULL Pointer Dereference in ldifutil.c
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10429 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 10375] New: [patch] minor patch to const up oids array
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10375 Issue ID: 10375 Summary: [patch] minor patch to const up oids array Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: caolanm(a)gmail.com Target Milestone: --- Created attachment 1084 --> https://bugs.openldap.org/attachment.cgi?id=1084&action=edit minor patch to const up oids array -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10379] New: lastbind change prevents ppolicy response from reaching accesslog
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10379 Issue ID: 10379 Summary: lastbind change prevents ppolicy response from reaching accesslog 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: --- When "lastbind on" and ppolicy are configured together, the pwdLastSuccess update triggers an accesslog entry (using op->o_time, op->o_tincr), then ppolicy_bind_response issues its own modification and since the time was copied in lastbind, an entry of the same name already exists. This means the ppolicy change is lost (and e.g. won't replicate). Note that slapo-lastbind (=the contrib overlay) probably has the same impact. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10370] New: result.c:930: try_read1msg: Assertion `!BER_BVISEMPTY( &resoid )' failed.
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10370 Issue ID: 10370 Summary: result.c:930: try_read1msg: Assertion `!BER_BVISEMPTY( &resoid )' failed. Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: daniel(a)haxx.se Target Milestone: --- When using curl built with OpenLDAP to access a broken/malicious ldap server, OpenLDAP will abort on this assert. It seems it should rather return a proper error code? A full reproducer that unfortunately uses curl is available here: https://hackerone.com/reports/3258022 together with more details about this problem. (I'm forwarding this information, I did not discover this.) -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10371] New: tools don't print useful error codes
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10371 Issue ID: 10371 Summary: tools don't print useful error codes Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- In tools/common.c, if ldap_result() returns an error, this return value is used directly as an LDAP error code in the subsequent call to tool_perror(). That is incorrect; ldap_result() always returns -1 on errors. The actual return code must be retrieved using ldap_get_option(ld, LDAP_OPT_RESULT_CODE,...). So up till now the tools have never printed the actual error message that's relevant to whatever failure occurred. Other applications appear to have copied this erroneous behavior. E.g., in investigating ITS#10370 I see that curl's code does the same thing. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10344] New: Potential memory leak in function firstComponentNormalize and objectClassPretty.
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10344 Issue ID: 10344 Summary: Potential memory leak in function firstComponentNormalize and objectClassPretty. Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: alexguo1023(a)gmail.com Target Milestone: --- Created attachment 1071 --> https://bugs.openldap.org/attachment.cgi?id=1071&action=edit Patch: Ensure the first argument passed to `ber_dupbv_x` is not `NULL`. In `firstComponentNormalize`, the code calls `ber_dupbv_x` but ignores its return value. ```c ber_dupbv_x(normalized, val, ctx); ``` When `normalized` is `NULL`, `ber_dupbv_x` allocates a new `struct berval` and returns it; failing to capture that pointer means we lose ownership and leak the allocation. The same issue arises in `objectClassPretty`. We should follow the pattern in function `hexNormalize`, which asserts that its `normalized` argument is non-NULL before use: ```c assert(normalized != NULL); ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10339] New: config_add_internal() use-after-free on failed cn=config mod
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10339 Issue ID: 10339 Summary: config_add_internal() use-after-free on failed cn=config mod 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: --- If overlay startup/callback fails, bconfig.c:5593 uses the value of ca->argv[1] despite it being freed already. I guess we can just log the entry's DN. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10329] New: Additional issues with pcache, and a test
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10329 Issue ID: 10329 Summary: Additional issues with pcache, and a test Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: aweits(a)rit.edu Target Milestone: --- Created attachment 1062 --> https://bugs.openldap.org/attachment.cgi?id=1062&action=edit test & patches Hello again! Further testing revealed some more issues in pcache [re: ITS#10270]. I've attached an update to test020-proxycache as well. These are based off the current git HEAD. -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 10366] New: Is 'second database definition & config directives' block duplicated?
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10366 Issue ID: 10366 Summary: Is 'second database definition & config directives' block duplicated? Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: truth_jp_4133(a)yahoo.co.jp Target Milestone: --- I have a question about an example of '6.1. Configuration File Format' section on this page (https://www.openldap.org/doc/admin26/slapdconfig.html). I think that 'second database definition & config directives' section is duplicated. Is the second 'second database definition & config directives' to be 'third database definition & config directives'? -- You are receiving this mail because: You are on the CC list for the issue.

1 5

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

29 Jan '26

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

1 0

[Issue 7901] slapschema reports error but returns 0
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=7901 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 10372] New: support lastbind_forward_updates outside of the lastbind overlay
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10372 Issue ID: 10372 Summary: support lastbind_forward_updates outside of the lastbind overlay Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: lklement(a)symas.com Target Milestone: --- according to the documentation for the LastBind overlay (slapo-lastbind) this overlay is no longer recommended unless lastbind_forward_updates is used. Can this functionality be added to the current lastbind configuration recommendation? -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10384] New: str2entry2() leaks attributes on error
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10384 Issue ID: 10384 Summary: str2entry2() leaks attributes on error 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: --- If there's error processing attribute values, the attribute list in ahead is not freed. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10335] New: [PATCH] ldapsearch: fix handling of -LL in print_reference()
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10335 Issue ID: 10335 Summary: [PATCH] ldapsearch: fix handling of -LL in print_reference() Product: OpenLDAP Version: 2.6.9 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: bolek(a)live.com Target Milestone: --- Created attachment 1066 --> https://bugs.openldap.org/attachment.cgi?id=1066&action=edit [PATCH] ldapsearch: fix handling of -LL in print_reference() I, Boleslaw Ciesielski, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. The attached patch (against master) fixes a bug in ldapsearch where the -LL (or -LLL) option is ignored when printing the reference comments in print_reference(). -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10191] New: backend searches should respond to pause requests
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10191 Issue ID: 10191 Summary: backend searches should respond to pause requests Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- A long running search will cause mods to cn=config to wait a long time. Search ops should periodically check for threadpool pause requests. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10391] New: Add proper compiler/linker flag for threading support on HP-UX
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10391 Issue ID: 10391 Summary: Add proper compiler/linker flag for threading support on HP-UX Product: OpenLDAP Version: 2.6.10 Hardware: Other OS: Other Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: michael.osipov(a)innomotics.com Target Milestone: --- Created attachment 1085 --> https://bugs.openldap.org/attachment.cgi?id=1085&action=edit Patch against master If an application uses a thread-enabled library or the application itself is thread enabled it is imperative on HP-UX to use the -mt flag through out build. The compiler will transform into proper -D and -l flags. From the manpage: -mt Sets various -D flags to enable multi-threading. Also sets -lpthread. +Oopenmp automatically implies -mt. For details see HP C/aC++ Online Programmer's Guide. Find a Git-formatted patch attached. Sample output: libtool: link: /opt/aCC/bin/aCC -AC99 +We901 -o ldapsearch ldapsearch.o common.o ldsversion.o -L/opt/ports/lib/hpux32 ../../libraries/liblutil/liblutil.a ../../libraries/libldap/.libs/libldap.a -L/opt/ports/lib /var/tmp/ports/work/openldap-threading-hpux/libraries/liblber/.libs/liblber.a ../../libraries/liblber/.libs/liblber.a /opt/ports/lib/hpux32/libsasl2.so -ldl -lssl -lcrypto -mt -Wl,+b -Wl,/opt/ports/lib/hpux32 -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10377] New: The words (addressbooks/addressbook) seems to be mismatched in the DIT example and the ACL example.
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10377 Issue ID: 10377 Summary: The words (addressbooks/addressbook) seems to be mismatched in the DIT example and the ACL example. Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: truth_jp_4133(a)yahoo.co.jp Target Milestone: --- In '8.4.8. Allowing entry creation' section, the DIT example is 'ou=addressbooks'. On the other hand, the ACL example is 'ou=addressbook,'. So the words (addressbooks/addressbook) seems to be mismatched in the DIT example and the ACL example. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10401] New: liblber: undefined shift of -1 in ber_decode_int()
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10401 Issue ID: 10401 Summary: liblber: undefined shift of -1 in ber_decode_int() Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Report from curl project. Full info here https://gist.github.com/bagder/44a0711fa1989951f2a2395fe992530e Relevant stack trace: [Environment] UBSAN_OPTIONS=exitcode=77:print_stacktrace=1:silence_unsigned_overflow=1 +----------------------------------------Release Build Stacktrace----------------------------------------+ Command: /mnt/scratch0/clusterfuzz/resources/platform/linux/unshare -c -n /mnt/scratch0/clusterfuzz/bot/builds/clusterfuzz-builds_curl_4cc8f5a06444eef5b5b6682762bec8608d45b81b/revisions/curl_fuzzer_ldap -rss_limit_mb=2560 -timeout=60 -runs=100 /mnt/scratch0/clusterfuzz/bot/inputs/fuzzer-testcases/crash-1364ab2dfa120fe4460381a08f4f158f8d47a30c Time ran: 0.14911556243896484 INFO: Running with entropic power schedule (0xFF, 100). INFO: Seed: 1947994398 INFO: Loaded 1 modules (211579 inline 8-bit counters): 211579 [0x559e5bb87a40, 0x559e5bbbb4bb), INFO: Loaded 1 PC tables (211579 PCs): 211579 [0x559e5bbbb4c0,0x559e5bef5c70), /mnt/scratch0/clusterfuzz/bot/builds/clusterfuzz-builds_curl_4cc8f5a06444eef5b5b6682762bec8608d45b81b/revisions/curl_fuzzer_ldap: Running 1 inputs 100 time(s) each. Running: /mnt/scratch0/clusterfuzz/bot/inputs/fuzzer-testcases/crash-1364ab2dfa120fe4460381a08f4f158f8d47a30c decode.c:316:21: runtime error: left shift of negative value -1 #0 0x559e5b730e08 in ber_decode_int curl_fuzzer/build/openldap/src/openldap_external/libraries/liblber/decode.c:316:21 #1 0x559e5b730c5d in ber_get_int curl_fuzzer/build/openldap/src/openldap_external/libraries/liblber/decode.c:293:9 #2 0x559e5b6e60f3 in try_read1msg curl_fuzzer/build/openldap/src/openldap_external/libraries/libldap/result.c:592:7 #3 0x559e5b6e60f3 in wait4msg curl_fuzzer/build/openldap/src/openldap_external/libraries/libldap/result.c:393:12 #4 0x559e5b6e60f3 in ldap_result curl_fuzzer/build/openldap/src/openldap_external/libraries/libldap/result.c:120:7 #5 0x559e5af804d6 in oldap_connecting curl/lib/openldap.c:826:10 #6 0x559e5aead984 in protocol_connecting curl/lib/multi.c:1794:14 #7 0x559e5aead984 in multi_runsingle curl/lib/multi.c:2510:16 #8 0x559e5aeacd4f in curl_multi_perform curl/lib/multi.c:2791:18 #9 0x559e5ae7fb38 in fuzz_handle_transfer(fuzz_data*) curl_fuzzer/curl_fuzzer.cc:419:5 #10 0x559e5ae7eff0 in LLVMFuzzerTestOneInput curl_fuzzer/curl_fuzzer.cc:97:3 #11 0x559e5add608d in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:619:13 #12 0x559e5adc0e02 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:329:6 #13 0x559e5adc6cd0 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:865:9 #14 0x559e5adf2802 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10 #15 0x7c4beb5b7082 in __libc_start_main /build/glibc-LcI20x/glibc-2.31/csu/libc-start.c:308:16 #16 0x559e5adb9eed in _start SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior decode.c:316:21 -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10374] New: pcache olcOverlay={0}pcache,olcDatabase={2}sql,cn=config: template index 0 invalid
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10374 Issue ID: 10374 Summary: pcache olcOverlay={0}pcache,olcDatabase={2}sql,cn=config: template index 0 invalid Product: OpenLDAP Version: 2.6.8 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: bertrand(a)jacquin.bzh Target Milestone: --- Hi, As a follow-up from https://bugs.openldap.org/show_bug.cgi?id=10373, it appears that the configuration I had shared can be converted to olc with slaptest, however does not pass validation be loaded when the daemon start: ``` $ slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d $ slaptest -u -F /etc/openldap/slapd.d -d stats -d pcache unrecognized log level "pcache" (deferred) Total # of attribute sets to be cached = 16. Template: query template: (mail=) attributes: * + Template: query template: (objectClass=*) attributes: * + Template: query template: (objectClass=*) attributes: mail Template: query template: (objectClass=) attributes: ou cn givenName sn mail telephoneNumber description jpegPhoto objectClass Template: query template: (objectClass=*) attributes: ou cn givenName sn mail telephoneNumber description jpegPhoto objectClass Template: query template: (&(objectClass=)(&(jpegPhoto=*)(|(mail=)))) attributes: ou cn givenName sn mail telephoneNumber description jpegPhoto objectClass Template: query template: (objectClass=) attributes: ou cn givenName sn mail telephoneNumber jid description jpegPhoto objectClass Template: query template: (objectClass=*) attributes: ou cn givenName sn mail telephoneNumber jid description jpegPhoto objectClass Template: query template: (&(objectClass=)(&(jpegPhoto=*)(|(mail=)))) attributes: ou cn givenName sn mail telephoneNumber jid description jpegPhoto objectClass Template: query template: (jid=) attributes: jid config error processing olcOverlay={0}pcache,olcDatabase={2}sql,cn=config: template index 0 invalid (0->15) slaptest: bad configuration directory! ``` From the following slapd.conf: ``` overlay pcache pcache mdb 65536 16 1024 60 directory /var/lib/openldap-data/pcache pcacheMaxQueries 1024 # No TTR, see https://bugs.openldap.org/show_bug.cgi?id=10373 # Cache DN pcacheAttrset 0 1.1 pcacheTemplate (objectClass=) 0 3600 60 0 pcacheTemplate (objectClass=*) 0 3600 60 0 pcacheTemplate (&(objectClass=)(&(jpegPhoto=*)(|(mail=)))) 0 3600 60 0 pcacheAttrset 1 jid pcacheTemplate (jid=) 1 3600 60 0 pcacheAttrset 2 ou cn givenname sn mail telephonenumber jid description jpegphoto objectClass pcacheTemplate (&(objectClass=)(&(jpegPhoto=*)(|(mail=)))) 2 3600 60 0 pcacheTemplate (objectClass=*) 2 3600 60 0 pcacheTemplate (objectClass=) 2 3600 60 0 pcacheAttrset 3 ou cn givenname sn mail telephonenumber description jpegphoto objectClass pcacheTemplate (&(objectClass=)(&(jpegPhoto=*)(|(mail=)))) 3 3600 60 0 pcacheTemplate (objectClass=*) 3 3600 60 0 pcacheTemplate (objectClass=) 3 3600 60 0 pcacheAttrset 4 mail pcacheTemplate (objectClass=*) 4 3600 60 0 pcacheAttrset 5 * + pcacheTemplate (objectClass=*) 5 3600 60 0 pcacheTemplate (mail=) 5 3600 60 0 ``` The following olc configuration get generated ``` $ cat /etc/openldap/slapd.d/cn=config/olcDatabase={2}sql/olcOverlay={0}pcache/olcDatabase={0}mdb.ldif # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 20578f61 dn: olcDatabase={0}mdb objectClass: olcMdbConfig objectClass: olcPcacheDatabase olcDatabase: {0}mdb olcDbDirectory: /var/lib/openldap-data/pcache olcDbNoSync: FALSE olcDbMaxReaders: 0 olcDbMaxSize: 10485760 olcDbMode: 0600 olcDbSearchStack: 16 olcDbMaxEntrySize: 0 olcDbRtxnSize: 10000 structuralObjectClass: olcMdbConfig entryUUID: ff5661e1-1259-4408-89a8-68f3c1b36095 creatorsName: cn=config createTimestamp: 20250724124836Z entryCSN: 20250724124836.628803Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20250724124836Z $ cat /etc/openldap/slapd.d/cn=config/olcDatabase={2}sql/olcOverlay={0}pcache.ldif # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 a8cfafe8 dn: olcOverlay={0}pcache objectClass: olcOverlayConfig objectClass: olcPcacheConfig olcOverlay: {0}pcache olcPcache: mdb 65536 16 1024 60 olcPcacheAttrset: 1 jid olcPcacheAttrset: 2 ou cn givenName sn mail telephoneNumber jid description jp egPhoto objectClass olcPcacheAttrset: 3 ou cn givenName sn mail telephoneNumber description jpegPh oto objectClass olcPcacheAttrset: 4 mail olcPcacheAttrset: 5 * + olcPcacheTemplate: "(mail=)" 5 3600 60 0 0 olcPcacheTemplate: "(objectClass=*)" 5 3600 60 0 0 olcPcacheTemplate: "(objectClass=*)" 4 3600 60 0 0 olcPcacheTemplate: "(objectClass=)" 3 3600 60 0 0 olcPcacheTemplate: "(objectClass=*)" 3 3600 60 0 0 olcPcacheTemplate: "(&(objectClass=)(&(jpegPhoto=*)(|(mail=))))" 3 3600 60 0 0 olcPcacheTemplate: "(objectClass=)" 2 3600 60 0 0 olcPcacheTemplate: "(objectClass=*)" 2 3600 60 0 0 olcPcacheTemplate: "(&(objectClass=)(&(jpegPhoto=*)(|(mail=))))" 2 3600 60 0 0 olcPcacheTemplate: "(jid=)" 1 3600 60 0 0 olcPcacheTemplate: "(&(objectClass=)(&(jpegPhoto=*)(|(mail=))))" 0 3600 60 0 0 olcPcacheTemplate: "(objectClass=*)" 0 3600 60 0 0 olcPcacheTemplate: "(objectClass=)" 0 3600 60 0 0 olcPcachePosition: tail olcPcacheMaxQueries: 1024 olcPcachePersist: FALSE olcPcacheValidate: FALSE olcPcacheOffline: FALSE structuralObjectClass: olcPcacheConfig entryUUID: dbee2888-2741-4298-abc3-81ae4bd9433a creatorsName: cn=config createTimestamp: 20250724124836Z entryCSN: 20250724124836.628803Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20250724124836Z ``` Is this a known limitation at the moment ? Cheers, Bertrand -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10388] New: ldif_parse_line2 is not compliant with RFC2849
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10388 Issue ID: 10388 Summary: ldif_parse_line2 is not compliant with RFC2849 Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- RFC2849: Any value that contains characters other than those defined as "SAFE-CHAR", or begins with a character other than those defined as "SAFE-INIT-CHAR", above, MUST be base-64 encoded. Other values MAY be base-64 encoded. SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B / %x3D-7F ; any value <= 127 except NUL, LF, CR, ; SPACE, colon (":", ASCII 58 decimal) ; and less-than ("<" , ASCII 60 decimal) However, if the value is not base64 encoded, ldif_parse_line2 (and consequently ldap_parse_ldif_record_x) uses isspace() to just skip any white-space characters at the beginning of at attribute value, icl. tabs. According to the RFC, however, such characters are acceptable. In addition, it does not return an error on LF or CR, just skips them. On the one hand, LDIFs are supposed to be human readable, and fixing this issue may lead to unexpected problems (e.g a stray tab being added to the attribute value). On the other hand, the standard does not exclude %x01-09 and %x0B-0C as valid characters for a non-encoded value. How should we proceed? -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10387] New: Reverse lookup does not work for IPv6 addresses proxied over IPv4
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10387 Issue ID: 10387 Summary: Reverse lookup does not work for IPv6 addresses proxied over IPv4 Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: +openldap(a)Eero.xn--Hkkinen-5wa.fi Target Milestone: --- I have an IPv4/IPv6 reverse proxy server which listens for ldap[s]:// connections and forwards them using the proxy procotol to an IPv4-only slapd server which listens for pldap[s]:// connections. The slapd server has the global olcReverseLookup setting set to TRUE. The reverse lookup works as expected if an LDAP client connects to the reverse proxy using IPv4. However, if the LDAP client connects to the reverse proxy using IPv6, the reverse lookup does not work. The slap_listener function in the servers/slapd/daemon.c file accepts a connection (https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_6_10/s…). Because the reverse proxy connects to the slapd server using the proxy protocol over IPv4, this fills the from variable with an IPv4 address and sets the len variable to the size of the struct sockaddr_in. This is correct. The slap_listener function detects that the connection is proxied (https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_6_10/s…) and uses the proxyp function to get the address of the LDAP client. This fills the from variable with an IPv4 or an IPv6 address (depending on whether the LDAP client used IPv4 or IPv6 to connect the reverse proxy) but does not update the len variable. The slap_listener function detects that reverse lookup is to be used (https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_6_10/s…) and used the ldap_pvt_get_hname function to get the reverse name (https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_6_10/s…) passing the address of the from variable, which may contain either an IPv4 or an IPv6 address, and the value of the len variable, which is equal to the size of the struct sockaddr_in. This is correct for IPv4 but not for IPv6. Either the slap_listener function or the proxyp function should update the value of the len variable. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10353] New: No TLS connection on Windows because of missing ENOTCONN in socket.h
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10353 Issue ID: 10353 Summary: No TLS connection on Windows because of missing ENOTCONN in socket.h Product: OpenLDAP Version: 2.6.10 Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: julien.wadel(a)belledonne-communications.com Target Milestone: --- On Windows, the TLS connection cannot be done and we get the connection error: Can't contact LDAP server. => Connections are done with WSAGetLastError(). After getting WSAEWOULDBLOCK, the connection is not restart because of the state WSAENOTCONN that is not known. OpenLDAP use ENOTCONN that is set to 126 by "ucrt/errno.h" while WSAENOTCONN is 10057L. Adding #define ENOTCONN WSAENOTCONN like for EWOULDBLOCK resolve the issue. Reference commit on external project: https://gitlab.linphone.org/BC/public/external/openldap/-/commit/62fbfb12e8… -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10345] New: Potential memory leak in function rbac_create_session
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10345 Issue ID: 10345 Summary: Potential memory leak in function rbac_create_session Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: alexguo1023(a)gmail.com Target Milestone: --- In `rbac_create_session`, we have the following code: ```c if ( rc < 0 ) { rs->sr_err = LDAP_OTHER; rs->sr_text = "internal error"; } else { (void)ber_flatten( ber, &rs->sr_rspdata ); rs->sr_rspoid = ch_strdup( slap_EXOP_CREATE_SESSION.bv_val ); // first rs->sr_err = LDAP_SUCCESS; } ber_free_buf(ber); done:; // always put the OID in the response: rs->sr_rspoid = ch_strdup( slap_EXOP_CREATE_SESSION.bv_val ); //second ``` The second `ch_strdup` at the `done` label overwrites `rs->sr_rspoid` without freeing the previous string, resulting in a memory leak. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10433] New: Copyright update to 2026
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10433 Issue ID: 10433 Summary: Copyright update to 2026 Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Update copyright to 2026 -- You are receiving this mail because: You are on the CC list for the issue.

1 4

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

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10343 Issue ID: 10343 Summary: Potential Memory Leak in function slap_uuidstr_from_normalized Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: alexguo1023(a)gmail.com Target Milestone: --- Created attachment 1070 --> https://bugs.openldap.org/attachment.cgi?id=1070&action=edit Patch: Change 1 to -1. In function slap_uuidstr_from_normalized, the code allocates a new `struct berval` with ```c new = (struct berval *)slap_sl_malloc(sizeof(struct berval), ctx); ``` and then attempt to allocate `new->bv_val`. If that second allocation fails, it sets `rc = 1` and jumps to the `done` cleanup label. However, the cleanup code only runs when `rc == -1`, so the memory pointed by `new` is never freed, causing a memory leak. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10400] New: NULL pointer deref in ldap_parse_result
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10400 Issue ID: 10400 Summary: NULL pointer deref in ldap_parse_result Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Report from curl project. Full info here https://gist.github.com/bagder/8aae731b05bf423205db3d71aaedf18c Relevant stack trace: [Environment] ASAN_OPTIONS=exitcode=77 +----------------------------------------Release Build Stacktrace----------------------------------------+ Command: /mnt/scratch0/clusterfuzz/resources/platform/linux/unshare -c -n /mnt/scratch0/clusterfuzz/bot/builds/clusterfuzz-builds_curl_d1a7f12cc2e5055727a9c66d5eca203f3c8f5a6c/revisions/curl_fuzzer_ldap -rss_limit_mb=2560 -timeout=60 -runs=100 /mnt/scratch0/clusterfuzz/bot/inputs/fuzzer-testcases/crash-0f193edf6a069aa877a89a9f31c6b4d0c47ff028 Time ran: 0.0964963436126709 INFO: Running with entropic power schedule (0xFF, 100). INFO: Seed: 2389202903 INFO: Loaded 1 modules (166249 inline 8-bit counters): 166249 [0x55ca1b31da20, 0x55ca1b346389), INFO: Loaded 1 PC tables (166249 PCs): 166249 [0x55ca1b346390,0x55ca1b5cfa20), /mnt/scratch0/clusterfuzz/bot/builds/clusterfuzz-builds_curl_d1a7f12cc2e5055727a9c66d5eca203f3c8f5a6c/revisions/curl_fuzzer_ldap: Running 1 inputs 100 time(s) each. Running: /mnt/scratch0/clusterfuzz/bot/inputs/fuzzer-testcases/crash-0f193edf6a069aa877a89a9f31c6b4d0c47ff028 AddressSanitizer:DEADLYSIGNAL ================================================================= ==402==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x55ca1ae33b22 bp 0x7ffd8c148e00 sp 0x7ffd8c148d00 T0) ==402==The signal is caused by a READ memory access. ==402==Hint: address points to the zero page. #0 0x55ca1ae33b22 in ldap_parse_result curl_fuzzer/build/openldap/src/openldap_external/libraries/libldap/error.c:264:26 #1 0x55ca1a3c0b45 in oldap_connecting curl/lib/openldap.c:844:10 #2 0x55ca1a25c34f in protocol_connecting curl/lib/multi.c:1794:14 #3 0x55ca1a25c34f in multi_runsingle curl/lib/multi.c:2510:16 #4 0x55ca1a25a985 in curl_multi_perform curl/lib/multi.c:2791:18 #5 0x55ca1a20c048 in fuzz_handle_transfer(fuzz_data*) curl_fuzzer/curl_fuzzer.cc:419:5 #6 0x55ca1a20afd7 in LLVMFuzzerTestOneInput curl_fuzzer/curl_fuzzer.cc:97:3 #7 0x55ca1a0a854d in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:619:13 #8 0x55ca1a0932c2 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:329:6 #9 0x55ca1a099190 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:865:9 #10 0x55ca1a0c4cc2 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10 #11 0x7d3b976eb082 in __libc_start_main /build/glibc-LcI20x/glibc-2.31/csu/libc-start.c:308:16 #12 0x55ca1a08c3ad in _start ==402==Register values: rax = 0x0000000000000000 rbx = 0x00007ffd8c148d00 rcx = 0x0000799b969e0e00 rdx = 0x0000000000000000 rdi = 0x0000799b969e0e00 rsi = 0x0000793b959d5920 rbp = 0x00007ffd8c148e00 rsp = 0x00007ffd8c148d00 r8 = 0x000055ca1b751a00 r9 = 0x00007fffffffff01 r10 = 0x00007fffffffff01 r11 = 0x0000000000000001 r12 = 0x0000793b956d2800 r13 = 0x0000000000000000 r14 = 0x0000000000000000 r15 = 0x0000000000000000 AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/mnt/scratch0/clusterfuzz/bot/builds/clusterfuzz-builds_curl_d1a7f12cc2e5055727a9c66d5eca203f3c8f5a6c/revisions/curl_fuzzer_ldap+0x1411b22) ==402==ABORTING -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10304] New: Unable to remove item from directory as part of transaction if it is the last item in that directory
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10304 Issue ID: 10304 Summary: Unable to remove item from directory as part of transaction if it is the last item in that directory Product: OpenLDAP Version: 2.5.13 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: sophie.elliott(a)arcticlake.com Target Milestone: --- I am running my ldap server on Debian 11.3, with the mdb backend, using the backported openldap version 2.5.13. I am not 100% certain if this is an issue with OpenLDAP or liblmdb, but I have been running tests in the repo and it looks like the liblmdb tests work fine, so I think it's with OpenLDAP itself. I have been performing a transaction, and deleting entries from a directory during this transaction. This works fine if the item that I am deleting isn't the last entry in its directory, but when it is I get a MDB_NOTFOUND error on the commit transaction call and the delete doesn't go through. Here is an excerpt of the logs when this happens: ``` 67a64334.14e1fc32 0x766ad2a00700 => index_entry_del( 108, "accessGroupID=f23de82f-3a1c-4f88-86bb-bb07f9a0992d,o=[COMPANY],ou=accessGroups,dc=local,dc=[COMPANY],dc=com" ) 67a64334.14e21912 0x766ad2a00700 mdb_idl_delete_keys: 6c [62d34624] 67a64334.14e22812 0x766ad2a00700 <= index_entry_del( 108, "accessGroupID=f23de82f-3a1c-4f88-86bb-bb07f9a0992d,o=[COMPANY],ou=accessGroups,dc=local,dc=[COMPANY],dc=com" ) success 67a64334.14e23a91 0x766ad2a00700 mdb_delete: txn_commit failed: MDB_NOTFOUND: No matching key/data pair found (-30798) ``` Please let me know if I should submit this issue elsewhere, or if this is something that has already been fixed in a more recent version. I'm also happy to provide more details if necessary. Thank you! -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10380] New: file logger doesn't emit slapd startup/version info
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10380 Issue ID: 10380 Summary: file logger doesn't emit slapd startup/version info 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: --- When using syslog, a startup message is emitted which is useful in many different contexts: - signals a slapd restart to the admin - shows the actual version used - if a crash happened just before, there is no "stopped" message, this is a hint to anyone looking that something was not right and the slapd is not the same process - people writing log processing scripts (incident response) know when it's necessary to reset their state, again as it's a new process Because of the above, it feels like a regression to me. I guess we can just emit this info on logfile config handlers? This means startups and logfile switches are still handled as they used to in syslog and log rotation doesn't emit anything (making it easy and safe to just concatenate files). Yes, slapd logs its PID in most formats so restarts can be detected that way, but that's considerably harder to search for. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10359] New: delta-MPR uses logbase for more than it documents
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10359 Issue ID: 10359 Summary: delta-MPR uses logbase for more than it documents 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: --- syncrepl logbase=<dn> is used not just for a syncrepl session (documented) but also for internal searches when it comes to delta-MPR conflict resolution. This is not documented so an admin doesn't know that the local accesslog DB needs to exist and have the same suffix. Either the documentation needs updating or a new configuration item needs to be added to allow an accesslog DB with a different suffix locally. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs