openldap-bugs August 2025

openldap-bugs@openldap.org

1 participants
161 discussions

[Issue 10341] New: Two potential buffer overruns in function mdb_cmp_cint.
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10341 Issue ID: 10341 Summary: Two potential buffer overruns in function mdb_cmp_cint. Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: alexguo1023(a)gmail.com Target Milestone: --- Created attachment 1068 --> https://bugs.openldap.org/attachment.cgi?id=1068&action=edit Patch: Fix buffer overrun in function mdb_cmp_cint We found two potential bugs in `mdb_cmp_cint`’s backward‐scan loop: ```c u = (unsigned short *)((char *)a->mv_data + a->mv_size); c = (unsigned short *)((char *)b->mv_data + a->mv_size); do { x = *--u - *--c; } while (!x && u > (unsigned short *)a->mv_data); ``` 1. **Underflow when `a->mv_size == 0`** If `a->mv_size` is zero, `u` is initialized to point one past the end of the zero‐length buffer. The first `--u` then moves it before `a->mv_data`, and the subsequent dereference is undefined. The original API allows lengths from 0 to `0xFFFFFFFF`, so a zero length is possible can could lead to pointer underflow here. 2. **Overflow of `b->mv_data` when `b->mv_size < a->mv_size`** The code uses `a->mv_size` to advance both `u` and `c`, and only bounds‐checks `u`. If `b->mv_size` is smaller than `a->mv_size`, `c` may run past the end of its buffer before the loop terminates, causing a buffer overrun. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10340] New: Potential Buffer Overflow in mdb_rebalance
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10340 Issue ID: 10340 Summary: Potential Buffer Overflow in mdb_rebalance Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: alexguo1023(a)gmail.com Target Milestone: --- Created attachment 1067 --> https://bugs.openldap.org/attachment.cgi?id=1067&action=edit Add an early return when `mc->mc_top == 0` In `mdb_rebalance`, we do: ```c int ptop = mc->mc_top - 1; node = mc->mc_pg[ptop]; ``` However, `mc->mc_top` defaults to 0 in many contexts, so `ptop` can become `-1`. Indexing `mc->mc_pg[-1]` causes invalid memory access. Elsewhere this is handled by checking `mc->mc_top > 0` before decrementing. To fix this, we add an early return when `mc->mc_top == 0`. A root page (or one without a parent) doesn’t need rebalancing, so this guard prevents `ptop` from ever being negative and eliminates the out-of-bounds access. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10132] New: manage syncrepl as a cn=config entry
by openldap-its＠openldap.org 27 Jan '26

27 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10132 Issue ID: 10132 Summary: manage syncrepl as a cn=config entry 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: --- Maybe it being exposed through both places (olcSyncrepl and the entry) could be a way to manage the transition (unless we have a way to handle cn=config schema upgrades internally). Uncertain as to how that affects cn=config replication. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9959] New: Expose the lloadd connection endpoints in cn=monitor for identification
by openldap-its＠openldap.org 12 Jan '26

12 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=9959 Issue ID: 9959 Summary: Expose the lloadd connection endpoints in cn=monitor for identification 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: --- ITS#9600 introduces a way to operate on lloadd connections, however it is impossible to identify which socket this actually corresponds to. While we're at it, might also expose the current bound identity there. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9884] New: Document "set" patterns in ACLs
by openldap-its＠openldap.org 06 Jan '26

06 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=9884 Issue ID: 9884 Summary: Document "set" patterns in ACLs Product: OpenLDAP Version: unspecified 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: --- The slapd.access(5) man page has this exceptionally unhelpful line where sets are concerned: "The statement set=<pattern> is undocumented yet." Even if it is an experimental feature, it should still be documented on how it is meant to operate. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10149] New: [PATCH] Allow certificates and keys to be read from URIs.
by openldap-its＠openldap.org 15 Dec '25

15 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=10149 Issue ID: 10149 Summary: [PATCH] Allow certificates and keys to be read from URIs. Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: minfrin(a)sharp.fm Target Milestone: --- Add the LDAP_OPT_X_TLS_URIS and LDAP_OPT_X_TLS_CACERTURIS options to allow certificates and keys to be set using OpenSSL provider URIs. The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Graham Leggett minfrin(a)sharp.fm. I have not assigned rights and/or interest in this work to any party. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2023 Graham Leggett Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. -- You are receiving this mail because: You are on the CC list for the issue.

1 13

[Issue 9577] New: slapd -V should be deprecated
by openldap-its＠openldap.org 15 Dec '25

15 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=9577 Issue ID: 9577 Summary: slapd -V should be deprecated Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: smckinney(a)symas.com Target Milestone: --- Sometimes a user's (present one included) ignorance gets them in trouble unnecessarily. The -V option is an example... Normally, when one wants to determine the version of a process, they use -V, or perhaps -v. With slapd, the daemon actually continues to run, which can have negative consequences. The doc clearly states that -VV is probably what the user wants, but is counter-intutive. Who RTFM's before checking the version? -V print version info (-VV exit afterwards, -VVV print info about static overlays and backends) I propose we eliminate the option to allow slapd to continue running after displaying the version. Perhaps we eliminate the -V option entirely, or just make it work the same as -VV. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10306] New: epoll, kqueue etc. are not used when cross compiling
by openldap-its＠openldap.org 15 Dec '25

15 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=10306 Issue ID: 10306 Summary: epoll, kqueue etc. are not used when cross compiling Product: OpenLDAP Version: 2.6.9 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: hi(a)alyssa.is Target Milestone: --- OpenLDAP's build system relies on running test programs to see whether epoll or kqueue are available, after checking the headers are available. When cross compiling, test programs can't be run, and even if they could, they wouldn't produce useful results because they'd be testing the build machine. Running test programs like this isn't even a great idea for native builds, because the package is still quite likely to end up running on a different machine than it was built for — think about distro packages. This means that cross-compiled OpenLDAP ends up using select, even though it could almost certainly use epoll or kqueue. The best thing to do for this sort of thing is to check at runtime whether the epoll/kqueue/whatever is available, and fall back if not, but this would probably be hard to implement in OpenLDAP. Other, easier, things that could be done to improve the situation would be: • Assume that epoll/kqueue are available if the headers are. It's very unlikely nowadays that a system with the headers won't actually have the API available. • If the AC_RUN_IFELSE checks are staying, make sure that they're all overridabel with configure flags or at least AC_CACHE_CHECK. There are also uses of AC_RUN_IFELSE for pthreads, which presumably have the same problem. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9305] New: ldap_connect_to_host: Return code from getaddrinfo() discarded, troubleshooting difficult
by openldap-its＠openldap.org 15 Dec '25

15 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=9305 Issue ID: 9305 Summary: ldap_connect_to_host: Return code from getaddrinfo() discarded, troubleshooting difficult Product: OpenLDAP Version: 2.4.46 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: minfrin(a)sharp.fm Target Milestone: --- When the ldap_connect_to_host() function sees a failure from getaddrinfo(), the meaningless return code -1 is returned. This makes troubleshooting difficult on a webserver, where the low level printf debugging is not practical. (gdb) step ldap_connect_to_host (ld=ld@entry=0x7fffc4002e10, sb=0x7fffc400b240, proto=1, srv=srv@entry=0x7fffc400b2f0, async=async@entry=0) at os-ip.c:543 543 { (gdb) next 546 ber_socket_t s = AC_SOCKET_INVALID; (gdb) 562 if ( srv->lud_host == NULL || *srv->lud_host == 0 ) { (gdb) 568 port = srv->lud_port; (gdb) 570 if( !port ) { (gdb) 578 switch(proto) { (gdb) 580 osip_debug( ld, (gdb) warning: Source file is more recent than executable. 71 return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest)); (gdb) 598 hints.ai_flags = AI_ADDRCONFIG; (gdb) 601 hints.ai_socktype = socktype; (gdb) 602 snprintf(serv, sizeof serv, "%d", port ); (gdb) 605 LDAP_MUTEX_LOCK(&ldap_int_resolv_mutex); (gdb) 607 err = getaddrinfo( host, serv, &hints, &res ); (gdb) 609 LDAP_MUTEX_UNLOCK(&ldap_int_resolv_mutex); (gdb) 611 if ( err != 0 ) { (gdb) 612 osip_debug(ld, "ldap_connect_to_host: getaddrinfo failed: %s\n", (gdb) print host $3 = <optimized out> (gdb) print serv $4 = "636\000\000\000" (gdb) next 614 return -1; (gdb) The ldap_connect_to_host() function needs to return proper error codes. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10361] New: lapo-auditlog: Add olcAuditLogNonBlocking to avoid blocking when logging to named pipes
by openldap-its＠openldap.org 15 Dec '25

15 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=10361 Issue ID: 10361 Summary: lapo-auditlog: Add olcAuditLogNonBlocking to avoid blocking when logging to named pipes Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: a.cudbardb(a)freeradius.org Target Milestone: --- Created attachment 1081 --> https://bugs.openldap.org/attachment.cgi?id=1081&action=edit Patch adding olcAuditlogNonBlocking and a tests for slapo-auditlog The default behaviour of fopen() when called on a named pipe which does not have any reader, is to block, until a reader opens the pipe. This in turn blocks slapo-auditlog when it attempts to write output, and prevents slapd processing requests. Depending on how critical the audit log is, it may be preferable to discard audit log output and continue processing requests if there's no reader available which olcAuditLogNonBlocking: TRUE allows. For clarity the call to fopen() is removed and replaced with open()/fdopen(), allowing us to specify O_* flags as opposed to using fopen() OR open()/fdopen() depending on whether we should block. 0666 are the base permissions used by fopen() when files are created. There were no tests for slapo-auditlog, so a small test suite that tests both the basic behaviour, and blocking/non-blocking writes. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

← Newer
1
...
9
10
11
12
13
14
15
16
17
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 August 2025