openldap-bugs

openldap-bugs@openldap.org

1 participants
21422 discussions

[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

[Issue 10503] saslauthz LDAP_X_SCOPE_GROUP fails to escape proxyAuthz asserted DN in internal group filter, enabling wildcard substring-filter group-membership bypass
by openldap-its＠openldap.org 19 May '26

19 May '26

https://bugs.openldap.org/show_bug.cgi?id=10503 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Status|IN_PROGRESS |RESOLVED --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • 9b55792b by Howard Chu at 2026-05-19T16:39:09+00:00 ITS#10503 authzTo: reject member attributes with non-DN syntax RE27: • 0c8a5875 by Howard Chu at 2026-05-19T22:36:36+00:00 ITS#10503 authzTo: reject member attributes with non-DN syntax RE26: • 41d7478a by Howard Chu at 2026-05-19T23:00:51+00:00 ITS#10503 authzTo: reject member attributes with non-DN syntax -- You are receiving this mail because: You are on the CC list for the issue.

1 0

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

19 May '26

https://bugs.openldap.org/show_bug.cgi?id=9009 --- Comment #1 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • 6e7690e8 by Howard Chu at 2026-05-19T17:06:20+01:00 ITS#9009 slapd-mdb: fix Makefile for LMDB 1.0 RE27: • 12656a7c by Howard Chu at 2026-05-19T22:36:27+00:00 ITS#9009 slapd-mdb: fix Makefile for LMDB 1.0 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10506] New: Remove back-sql from OpenLDAP 2.7
by openldap-its＠openldap.org 19 May '26

19 May '26

https://bugs.openldap.org/show_bug.cgi?id=10506 Issue ID: 10506 Summary: Remove back-sql from OpenLDAP 2.7 Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- back-sql was deprecated with OpenLDAP 2.6. Remove it from OpenLDAP 2.7 -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10504] New: Linker warning on newer build tools
by openldap-its＠openldap.org 19 May '26

19 May '26

https://bugs.openldap.org/show_bug.cgi?id=10504 Issue ID: 10504 Summary: Linker warning on newer build tools Product: LMDB Version: unspecified Hardware: All OS: Mac OS Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Newer linker complains ld: warning: symbols in __TEXT,text_env (/Users/selsta/dev/monero/build/Darwin/master/release/external/db_drivers/liblmdb/liblmdb.a[2](mdb.c.o)) have unwind information, but it's not a code section (missing 'regular,pure_instructions' section flag) When built with > clang --version Apple clang version 21.0.0 (clang-2100.1.1.101) Target: arm64-apple-darwin25.5.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin > ld -v @(#)PROGRAM:ld PROJECT:ld-1267 BUILD 17:51:50 Apr 22 2026 configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em armv8m.main armv8.1m.main will use ld-classic for: armv6 armv7 armv7s i386 armv6m armv7k armv7m armv7em LTO support using: LLVM version 21.0.0 (static support for 30, runtime is 30) TAPI support using: Apple TAPI version 21.0.0 (tapi-2100.0.2.6) As reported on https://github.com/monero-project/monero/pull/10585 Adding the missing flags silences the warning. Works fine on older toolchains as well. Apple docs are a bit ambiguous about whether "pure_instructions" is required or valid on static builds. https://developer.apple.com/library/archive/documentation/DeveloperTools/Re… -- You are receiving this mail because: You are on the CC list for the issue.

1 3

19 May '26

1 0

[Issue 10480] New: Use after free in cn=config replication
by openldap-its＠openldap.org 18 May '26

18 May '26

https://bugs.openldap.org/show_bug.cgi?id=10480 Issue ID: 10480 Summary: Use after free in cn=config replication Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- If a renumber needs to happen, cn=config frees e->e_name, but some code (e.g. syncrepl) sets op->o_req_dn to point to the same and as such it can't be used anymore. This causes a crash in syncrepl (if LDAP_DEBUG_SYNC is on) and accesslog during cn=config replication. Either syncrepl (and others) shouldn't do this or cn=config should check for this case and adjust o_req_dn after the fact. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 8605] spelling
by openldap-its＠openldap.org 15 May '26

15 May '26

https://bugs.openldap.org/show_bug.cgi?id=8605 --- Comment #9 from Quanah Gibson-Mount <quanah(a)openldap.org> --- mdb.master: 2216dbd9ee8d5c7a4b4d22e59e5831ed9cae32af mdb.master3: 93c460b8e4607558a9faf8f53d65468c25d73a12 mdb/RE1.0: f3ef35bbfbaaab8984b1a4eeb553643fb507862f mdb/RE0.9: 8aa8c1976f2d8e7db2240445700053d2a3a53c88 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

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