openldap-bugs

openldap-bugs@openldap.org

1 participants
21509 discussions

[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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs