openldap-bugs June 2025

openldap-bugs@openldap.org

1 participants
110 discussions

[Issue 10296] New: Force a Mac OS full flush
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10296 Issue ID: 10296 Summary: Force a Mac OS full flush 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: renault.cle(a)gmail.com Target Milestone: --- Created attachment 1045 --> https://bugs.openldap.org/attachment.cgi?id=1045&action=edit Use a F_FULLFSYNC fcntl when committing on Mac OS Hello Howard and Happy New Year, As discussed in this issue [1], the LMDB durability is incorrect when committing. I propose the following patch that uses fcntl with the F_FULLFSYNC flag. The fcntl documentation is on this page [2]. Note that I kept the calls to msync/fsync for simplicity and because they don't cost much but feel free to skip them on Mac OS. Have a nice day, kero [1]: https://github.com/cberner/redb/pull/928#issuecomment-2567032808 [2]: https://developer.apple.com/library/archive/documentation/System/Conceptual… -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 10342] New: Potential Memory Leak in function mdb_txn_begin
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10342 Issue ID: 10342 Summary: Potential Memory Leak in function mdb_txn_begin 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 1069 --> https://bugs.openldap.org/attachment.cgi?id=1069&action=edit Free txn->mt_u.dirty_list before freeing txn The function `mdb_txn_begin` allocates the dirty list via ```c txn->mt_u.dirty_list = malloc(sizeof(MDB_ID2) * MDB_IDL_UM_SIZE); ``` Later, when `txn != env->me_txn0`, it calls ```c free(txn); ``` without first freeing `txn->mt_u.dirty_list`. This orphaned allocation leads to a memory leak. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10346] New: mdb_env_copy2 on a database with a value larger than (2GB-16) results in a corrupt copy
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10346 Issue ID: 10346 Summary: mdb_env_copy2 on a database with a value larger than (2GB-16) results in a corrupt copy Product: LMDB Version: 0.9.31 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: mike.moritz(a)vertex.link Target Milestone: --- Created attachment 1072 --> https://bugs.openldap.org/attachment.cgi?id=1072&action=edit reproduction source code Running mdb_env_copy2 with compaction on a database with a value larger than (2GB-16)bytes appears to complete successfully in that there are no errors, but the copied database cannot be opened and throws an MDB_CORRUPTED error. Looking at the copied database size, it appears that the value is either being skipped or significantly truncated. Running mdb_env_copy2 without compaction also completes successfully, and the copied database can be opened. I initially encountered this while using py-lmdb with v0.9.31 of LMDB, but was able to write up a simple script that uses the library directly. The source for the script is attached, and the results below are from running it with the latest from master. Without compaction: $ ./lmdb_repro test.lmdb $((2 * 1024 * 1024 * 1024 - 16 + 1)) testbak.lmdb LMDB Version: LMDB 0.9.70: (December 19, 2015) Set LMDB map size to 21474836330 bytes Successfully inserted key with 2147483633 bytes of zero-filled data Retrieved 2147483633 bytes of data First 16 bytes (hex): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... Copying database to testbak.lmdb... Database copy completed successfully. Opening copied database and reading value... Retrieved 2147483633 bytes of data from copied database First 16 bytes from copy (hex): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... Data size matches between original and copy With compaction: $ ./lmdb_repro -c test.lmdb $((2 * 1024 * 1024 * 1024 - 16 + 1)) testbak.lmdb LMDB Version: LMDB 0.9.70: (December 19, 2015) Set LMDB map size to 21474836330 bytes Successfully inserted key with 2147483633 bytes of zero-filled data Retrieved 2147483633 bytes of data First 16 bytes (hex): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... Copying database to testbak.lmdb (with compaction)... Database copy completed successfully. Opening copied database and reading value... mdb_get (copy) failed: MDB_CORRUPTED: Located page was wrong type Size difference on corrupt DB: $ du -sh ./* 312K ./lmdb_repro 24K ./testbak.lmdb 2.1G ./test.lmdb With compaction at the perceived max size: $ ./lmdb_repro -c test.lmdb $((2 * 1024 * 1024 * 1024 - 16)) testbak.lmdb LMDB Version: LMDB 0.9.70: (December 19, 2015) Set LMDB map size to 21474836320 bytes Successfully inserted key with 2147483632 bytes of zero-filled data Retrieved 2147483632 bytes of data First 16 bytes (hex): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... Copying database to testbak.lmdb (with compaction)... Database copy completed successfully. Opening copied database and reading value... Retrieved 2147483632 bytes of data from copied database First 16 bytes from copy (hex): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... Data size matches between original and copy -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10355] New: mplay doesn't compile on musl
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10355 Issue ID: 10355 Summary: mplay doesn't compile on musl Product: LMDB Version: 0.9.33 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: tools Assignee: bugs(a)openldap.org Reporter: bgilbert(a)backtick.net Target Milestone: --- With the musl C library (e.g. Alpine Linux) mplay doesn't compile: gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -c mplay.c mplay.c: In function 'addpid': mplay.c:490:23: error: assignment of read-only variable 'stdin' 490 | stdin = fdopen(0, "r"); | ^ mplay.c:491:24: error: assignment of read-only variable 'stdout' 491 | stdout = fdopen(1, "w"); | ^ make: *** [Makefile:99: mplay.o] Error 1 -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[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 13 Jan '26

13 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 9796] New: Deprecate GnuTLS support
by openldap-its＠openldap.org 06 Jan '26

06 Jan '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 4

← Newer
1
2
3
4
5
6
7
...
11
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2025