- openldap-bugs - openldap.org

[Issue 10368] New: Must revert ITS#9849 license changes
by openldap-its＠openldap.org 02 Mar '26

02 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10368 Issue ID: 10368 Summary: Must revert ITS#9849 license changes Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: major Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- The changes related to license.wml made for ITS#9849 must be reverted. There is only one OpenLDAP Public License and it applies to all OpenLDAP software. There are not two different licenses for release/LTS. No single person has the right to alter the existing license. Currently the website is broken, as https://openldap.org/software/release/license.html is an empty file. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10337] New: Global TLS options not inherited in context
by openldap-its＠openldap.org 24 Feb '26

24 Feb '26

https://bugs.openldap.org/show_bug.cgi?id=10337 Issue ID: 10337 Summary: Global TLS options not inherited in context Product: OpenLDAP Version: 2.6.9 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: remi(a)fedoraproject.org Target Milestone: --- During ldap_create, global options are copied See https://github.com/openldap/openldap/blob/OPENLDAP_REL_ENG_2_6_9/libraries/… /* copy the global options */ AC_MEMCPY(&ld->ld_options, gopts, sizeof(ld->ld_options)); But not the TLS string options See https://github.com/openldap/openldap/blob/OPENLDAP_REL_ENG_2_6_9/libraries/… /* We explicitly inherit the SSL_CTX, don't need the names/paths. Leave * them empty to allow new SSL_CTX's to be created from scratch. */ memset( &ld->ld_options.ldo_tls_info, 0, sizeof( ld->ld_options.ldo_tls_info )); ld->ld_options.ldo_tls_ctx = NULL; Which create inconsistency when trying to generate a newctx For the context See * https://github.com/php/php-src/issues/17776 => why tls_newctx is needed * https://github.com/php/php-src/issues/18529 => regression On PHP side a possible workaround is to do the copyu manually * https://github.com/php/php-src/pull/18547 But should probably be handled at openldap library -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10404] New: slapd uses all available memory and starts using swap
by openldap-its＠openldap.org 23 Feb '26

23 Feb '26

https://bugs.openldap.org/show_bug.cgi?id=10404 Issue ID: 10404 Summary: slapd uses all available memory and starts using swap Product: OpenLDAP Version: 2.6.10 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: tomas.bjorklund(a)su.se Target Milestone: --- We have a problem with slapd using more and more memory until in starts using swap. We are using mdb and our maxsize is set to 8192000000. The server has 32GB of ram. data.mdb is around 2.6 GB Some settings from our slapd.conf: sizelimit 5000 timelimit 600 checkpoint 1024 15 loglevel sync stats This is how it looks with top: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 314486 root 20 0 31.6g 26.2g 2.6g S 16.3 83.7 8,09 slapd Depending on the load of the server it usually takes 2 weeks until all memory has been used. Things that we have tried: Changed swapiness to 1 Changed slapd service to use this: [Service] Environment="LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libtcmalloc_minimal.so.4" LimitCORE=infinity LimitNOFILE=4096 Restart=on-failure TimeoutStopSec=900 Everything worked fine with bdb and cache settings like: cachesize 100000 idlcachesize 100000 But since switching to mdb we run out of memory. -- You are receiving this mail because: You are on the CC list for the issue.

1 26

[Issue 10453] Security Vulnerability Report: Multiple CWE-22, CWE-416 and CWE-476 Issues Identified
by openldap-its＠openldap.org 17 Feb '26

17 Feb '26

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

1 0

[Issue 10453] Security Vulnerability Report: Multiple CWE-22, CWE-416 and CWE-476 Issues Identified
by openldap-its＠openldap.org 13 Feb '26

13 Feb '26

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

1 0

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

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

[Issue 9513] New: Enhanced debug output
by openldap-its＠openldap.org 12 Feb '26

12 Feb '26

https://bugs.openldap.org/show_bug.cgi?id=9513 Issue ID: 9513 Summary: Enhanced debug output Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: enhancement Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- While debugging ITS#9479 I needed more information on which threads were doing what actions. Also, when looking for delays/hangs/race conditions, the 1-second granularity of the debug msg timestamp was inadequate. And also, some of the debug output for the Search operation was being done in separate Debug calls for a single line of output. This gets jumbled up pretty badly if other threads are printing output as well. New patch set will extend the debug timestamp to have fractional seconds too; it will use clock_gettime for nanosecond resolution if available, otherwise use gettimeofday for microsecond resolution. Also tweak the Search debug output to only use one Debug invocation per line of output. This is MR!279. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9022] Force slapadd to rewrite all entryCSN values
by openldap-its＠openldap.org 12 Feb '26

12 Feb '26

https://bugs.openldap.org/show_bug.cgi?id=9022 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.7.1 |2.7.0 Status|UNCONFIRMED |RESOLVED Resolution|--- |TEST --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- • 1780b212 by Ondřej Kuzník at 2026-02-09T18:41:47+00:00 ITS#9022 Introduce -o remove-sids= to slapadd -- You are receiving this mail because: You are on the CC list for the issue.

1 0

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

10 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 3

[Issue 10452] New: Potential NULL dereference in slap_acl_mask()
by openldap-its＠openldap.org 10 Feb '26

10 Feb '26

https://bugs.openldap.org/show_bug.cgi?id=10452 Issue ID: 10452 Summary: Potential NULL dereference in slap_acl_mask() Product: OpenLDAP Version: 2.6.8 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: nastentsiya.filimonova(a)gmail.com Target Milestone: --- I've noticed potentially inconsistent NULL checks for the op->o_conn field in function slap_acl_mask (source file openldap-2.6.8/servers/slapd/acl.c). At first, op->o_conn is explicitly checked for NULL: if ( op->o_conn && !BER_BVISNULL( &op->o_conn->c_ndn ) ) { ndn = op->o_conn->c_ndn; } else { ndn = op->o_ndn; } This suggests that op->o_conn may indeed be NULL in some scenarios. However, right after that in the same function there are several unconditional dereferences of op->o_conn without a preceding NULL check, for example: if ( !op->o_conn->c_listener ) { continue; } if ( !op->o_conn->c_peer_domain.bv_val ) { continue; } if ( !op->o_conn->c_peer_name.bv_val ) { continue; } Could you please clarify whether op->o_conn is guaranteed to be non-NULL for all possible paths reaching these code sections? If op->o_conn can indeed be NULL here, these dereferences may lead to a NULL pointer dereference and would require additional checks. If op->o_conn is guaranteed to be non-NULL by design, please confirm this (it would also be useful to document this assumption explicitly). Thank you. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs