openldap-bugs

openldap-bugs@openldap.org

1 participants
21354 discussions

[Issue 9009] 2.7: Switch to LMDB v1.0
by openldap-its＠openldap.org 26 May '26

26 May '26

https://bugs.openldap.org/show_bug.cgi?id=9009 --- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • aa02d9f5 by Howard Chu at 2026-05-22T03:51:12+01:00 ITS#9009 slapd-mdb: refix Makefile RE27: • 7ae0869b by Howard Chu at 2026-05-22T19:12:49+00:00 ITS#9009 slapd-mdb: refix Makefile -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10512] New: systemd exec - update to absolute path
by openldap-its＠openldap.org 26 May '26

26 May '26

https://bugs.openldap.org/show_bug.cgi?id=10512 Issue ID: 10512 Summary: systemd exec - update to absolute path Product: OpenLDAP Version: 2.6.10 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: daniel(a)iamniz.co.uk Target Milestone: --- Could the ExecStart option in the systemd unit file be updated to use a absolute path? ERROR:systemctl: slapd.service: Exec is not an absolute path: ExecStart=sh -c 'mkdir -p /run/slapd; \ chown "$SLAPD_USER":"$SLAPD_GROUP" /run/slapd; \ [ -d "$SLAPD_CONF" ] && confflag=-F || confflag=-f; \ exec /usr/sbin/slapd -d0 \ ${SLAPD_SERVICES:+-h "$SLAPD_SERVICES"} \ ${SLAPD_USER:+-u "$SLAPD_USER"} \ ${SLAPD_GROUP:+-g "$SLAPD_GROUP"} \ ${SLAPD_CONF:+$confflag "$SLAPD_CONF"} \ $SLAPD_OPTIONS' ERROR:systemctl: slapd.service: Exec command does not exist: (ExecStart) sh ERROR:systemctl: slapd.service: but this does exist: /usr/bin/sh ERROR:systemctl: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ERROR:systemctl: The SystemD ExecXY commands must always be absolute paths by definition. ERROR:systemctl: Oops, 1 executable paths were not found in the current environment. Refusing. ERROR:systemctl: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Regards, Dan Nisbet -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10488] New: Multiple out-of-bounds reads in servers/slapd/result.c v2ref() function
by openldap-its＠openldap.org 22 May '26

22 May '26

https://bugs.openldap.org/show_bug.cgi?id=10488 Issue ID: 10488 Summary: Multiple out-of-bounds reads in servers/slapd/result.c v2ref() function Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: wangxiaomeng(a)kylinos.cn Target Milestone: --- Created attachment 1142 --> https://bugs.openldap.org/attachment.cgi?id=1142&action=edit Fix two out-of-bounds reads in servers/slapd/result.c v2ref() function The v2ref() function in servers/slapd/result.c is responsible for converting LDAPv3 referrals to an LDAPv2-compatible string format. Two separate out-of-bounds read vulnerabilities exist in this function, both caused by insufficient checks for zero-length data before accessing the last character of the data buffer. Vulnerability 1: Out-of-bounds read in text buffer handling Location: servers/slapd/result.c, line 94 (within the v2ref() function): Vulnerable Code: if ( text != NULL ) { len = strlen( text ); if (text[len-1] != '\n') { i = 1; } } When the 'text' parameter is non-NULL but points to an empty string (""), strlen(text) returns 0. Accessing text[len-1] (i.e., text[-1]) results in an out-of-bounds read of one byte before the start of the 'text' buffer. Vulnerability 2: Out-of-bounds read in BerValue referral handling Location: servers/slapd/result.c, line 115 (within the v2ref() function) Vulnerable Code: len += ref[i].bv_len; if (ref[i].bv_val[ref[i].bv_len-1] != '/') { ++len; } When ref[i].bv_val is non-NULL but ref[i].bv_len is 0 (a valid state per LDAP BerValue semantics, representing an empty string), accessing ref[i].bv_val[ref[i].bv_len-1] (i.e., ref[i].bv_val[-1]) results in an out-of-bounds read of one byte before the start of the ref[i].bv_val buffer. Fix Add checks for zero-length data before accessing the last character of the respective buffers. The fix addresses both vulnerabilities with minimal, targeted changes that preserve the original functionality. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 10511] New: Add pagesize setting to back-mdb
by openldap-its＠openldap.org 20 May '26

20 May '26

https://bugs.openldap.org/show_bug.cgi?id=10511 Issue ID: 10511 Summary: Add pagesize setting to back-mdb Product: OpenLDAP Version: unspecified 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: --- With LMDB 1.0, the DB pagesize is now configurable. Add an option to back-mdb to support this. Larger page sizes accommodate larger keys, which is also helpful when using multival. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10510] New: write_coherence can assert() on unbind
by openldap-its＠openldap.org 20 May '26

20 May '26

https://bugs.openldap.org/show_bug.cgi?id=10510 Issue ID: 10510 Summary: write_coherence can assert() on unbind 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: --- If lloadd links a client with a backend and that client issues a write and unbind in quick succession, the self-checks in client_reset are overly strict, triggering an assert. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9796] New: Deprecate GnuTLS support
by openldap-its＠openldap.org 20 May '26

20 May '26

https://bugs.openldap.org/show_bug.cgi?id=9796 Issue ID: 9796 Summary: Deprecate GnuTLS support Product: OpenLDAP Version: 2.6.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Support for GnuTLS was added specifically for the Debian (and thus Ubuntu) due to the license objections at the time that the Debian project had for the OpenSSL license. Since that time, Debian has reclassified OpenSSL as a core library and the OpenSSL project has resolved the original complaint by licensing OpenSSL 3 and later under the Apache License v2. Thus there is no longer a reason to maintain support for GnuTLS and given the long standing concerns over the security and quality of the GnuTLS bridge in addition to the extra cost of maintaining that code, it should be marked as deprecated and removed in a future release. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10502] New: feature proxyauthz should become default
by openldap-its＠openldap.org 20 May '26

20 May '26

https://bugs.openldap.org/show_bug.cgi?id=10502 Issue ID: 10502 Summary: feature proxyauthz should become default 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: --- Most stock lloadd deployments are against OpenLDAP, but since "feature" keyword doesn't allow "off-switches", proxyauthz has had to have been an "off by default" thing. This is insecure and probably a footgun for many. We'll have to introduce a new configuration option to do this, one that allows for gentler evolution. This also allows us to reject a bindconf+no_proxyauthz combinations if we force the rare admins who genuinely need it (no proxyauthz support in upstreams) to opt in explicitly. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10415] New: Allow limiting the buffers for data pending to be sent to client
by openldap-its＠openldap.org 20 May '26

20 May '26

https://bugs.openldap.org/show_bug.cgi?id=10415 Issue ID: 10415 Summary: Allow limiting the buffers for data pending to be sent to client 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: --- In many scenarios it is more useful to limit the amount of data we buffer to be written to the client's socket even if it means that sometimes a connection might have to be dropped abruptly to enforce this. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

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

20 May '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 13

[Issue 10505] New: lloadd doesn't fully validate incoming msgids
by openldap-its＠openldap.org 19 May '26

19 May '26

https://bugs.openldap.org/show_bug.cgi?id=10505 Issue ID: 10505 Summary: lloadd doesn't fully validate incoming msgids 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: --- This can allow rogue clients reach an assert(0) with the right timing. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

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