openldap-bugs December 2020

openldap-bugs@openldap.org

3 participants
89 discussions

[Issue 9391] New: (entryUUID=foobar) -> seg fault
by openldap-its＠openldap.org 18 Jan '21

18 Jan '21

https://bugs.openldap.org/show_bug.cgi?id=9391 Issue ID: 9391 Summary: (entryUUID=foobar) -> seg fault Product: OpenLDAP Version: 2.4.56 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- Searching with filter (entryUUID=foobar) crashes slapd for Æ-DIR providers and consumers. Log message: slapd: schema_init.c:2943: UUIDNormalize: Assertion `val->bv_len == 16' failed. Let me know if you need more information to reproduce. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9430] New: mdb_put() with MDB_RESERVE | MDB_NOOVERWRITE sets 'data' to invalid memory
by openldap-its＠openldap.org 30 Dec '20

30 Dec '20

https://bugs.openldap.org/show_bug.cgi?id=9430 Issue ID: 9430 Summary: mdb_put() with MDB_RESERVE | MDB_NOOVERWRITE sets 'data' to invalid memory Product: LMDB Version: unspecified Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: kenta(a)lithdew.net Target Milestone: --- Running on NixOS (x86_64-linux). The following sequence of methods was called with an MDB_env and MDB_txn created with default flags, with the MDB_txn open on MAIN_DBI. The following code is pseudocode - should the code not be clear enough, happy to provide the original test case which was written in Zig (https://ziglang.org). // Put KV pair ('hello', 'test'). var k: MDB_val = .{ .mv_size = "hello".len, .mv_data = &"hello" }; var v: MDB_val = .{ .mv_size = "test".len, .mv_data = &"test" }; mdb_put(txn, MAIN_DBI, &k, &v, 0); // Attempt to put KV pair ('hello', 'world!') with MDB_RESERVE | MDB_NOOVERWRITE, and assert that it fails. var k2: MDB_val = .{ .mv_size = "hello".len, .mv_data = &"hello" }; var v2: MDB_val = .{ .mv_size = "world!".len, .mv_data = null }; assert(mdb_put(txn, MAIN_DBI, &k2, &v2, MDB_RESERVE | MDB_NOOVERWRITE) == MDB_KEYEXIST); // Assertion fails. assert(v2 == v); After these steps, it is expected that v2's 'mv_data' points to 'test' with a 'mv_size' of 4 (the previously, successfully-written KV pair). What actually happened was that v2's 'mv_size' was correctly set to 4, though 'mv_data' points to garbage memory. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9429] New: LMDB mdb_del and mdb_cursor_del cause MDB_MAP_FULL on Apple M1
by openldap-its＠openldap.org 23 Dec '20

23 Dec '20

https://bugs.openldap.org/show_bug.cgi?id=9429 Issue ID: 9429 Summary: LMDB mdb_del and mdb_cursor_del cause MDB_MAP_FULL on Apple M1 Product: LMDB Version: 0.9.26 Hardware: Other OS: Mac OS Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: simonleier(a)gmail.com Target Milestone: --- I discovered that deleting data from the database causes MDB_MAP_FULL on my MacBook Pro with M1 chip. The same code works fine on an Intel Mac. I think there is no special code required to reproduce this. Open a db, put something, try to delete it and LMDB crashes. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 8372] Incomplete members from dynlist group when Paged Results control is specified
by openldap-its＠openldap.org 16 Dec '20

16 Dec '20

https://bugs.openldap.org/show_bug.cgi?id=8372 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9426 --- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> --- May be duplicate of Issue#9426 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9397] New: LMDB: A second process opening a file with MDB_WRITEMAP can cause the first to SIGBUS
by openldap-its＠openldap.org 12 Dec '20

12 Dec '20

https://bugs.openldap.org/show_bug.cgi?id=9397 Issue ID: 9397 Summary: LMDB: A second process opening a file with MDB_WRITEMAP can cause the first to SIGBUS Product: LMDB Version: 0.9.26 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: github(a)nicwatson.org Target Milestone: --- Created attachment 780 --> https://bugs.openldap.org/attachment.cgi?id=780&action=edit Full reproduction of SIGBUS MDB_WRITEMAP issue (works on Linux only) The fundamental problem is that a ftruncate() on Linux that makes a file smaller will cause accesses past the new end of the file to SIGBUS (see the mmap man page). The sequence that causes a SIGBUS involves two processes. 1. The first process opens a new LMDB file with MDB_WRITEMAP. 2. The second process opens the same LMDB file with MDB_WRITEMAP and with an explicit map_size smaller than the first process's map size. * This causes an ftruncate that makes the underlying file *smaller*. 3. (Optional) The second process closes the environment and exits. 4. The first process opens a write transaction and writes a bunch of data. 5. The first process commits the transaction. This causes a memory read from the mapped memory that's now past the end of the file. On Linux, this triggers a SIGBUS. Attached is code that fully reproduces the problem on Linux. The most straightforward solution is to allow ftruncate to *reduce* the file size if it is the only reader. Another possibility is check the file size and ftruncate if necessary every time a write transaction is opened. A third possibility is to catch the SIGBUS signal. Repro note: I used clone() to create the subprocess to most straightforwardly demonstrate that the problem is not due to inherited file descriptors. The problem still manifests when the processes are completely independent. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 9418] New: slapd-bconfig: potential nullptr deref
by openldap-its＠openldap.org 05 Dec '20

05 Dec '20

https://bugs.openldap.org/show_bug.cgi?id=9418 Issue ID: 9418 Summary: slapd-bconfig: potential nullptr deref Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: danix800(a)gmail.com Target Milestone: --- Reported by clang static analyzer in servers/slapd/bconfig.c:6429 'ce->ce_parent' is potentially nullptr dereference based on the above test of 'ce->ce_parent' against null before 'access_allowed' is called, so it's better to check again. See MR!208 for a potential fix. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 6036] Crash: UUIDNormalize doesn't clear output on error
by openldap-its＠openldap.org 05 Dec '20

05 Dec '20

https://bugs.openldap.org/show_bug.cgi?id=6036 --- Comment #5 from amez365 <fieldengineer59(a)yahoo.com> --- Infrastructure Engineer https://www.fieldengineer.com/skills/what-is-an-infrastructure-engineer Infrastructure Engineer's roles include being responsible for designing, building, implementing and maintaining the IT infrastructure using the latest technology. An IT infrastructure engineer ensures that all IT systems that support businesses of any size operate efficiently. https://www.fieldengineer.com/skills/what-is-an-infrastructure-engineer -- You are receiving this mail because: You are on the CC list for the issue.

4 3

[Issue 8528] Incorrect results on replace op for olcAccess
by openldap-its＠openldap.org 02 Dec '20

02 Dec '20

https://bugs.openldap.org/show_bug.cgi?id=8528 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|OL_2_5_REQ | -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9415] New: Possible use of memory after free
by openldap-its＠openldap.org 02 Dec '20

02 Dec '20

https://bugs.openldap.org/show_bug.cgi?id=9415 Issue ID: 9415 Summary: Possible use of memory after free Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: cwe(a)skov.dk Target Milestone: --- In my code I have a construct like this: err = mdb_txn_commit(txn); if (err) { mdb_txn_abort(txn); } I run codesonar on my code and include the lmdb source in the run. Codesonar reports a possible double free for the case where mdb_midl_append_list in mdb.c line 3586 returns ENOMEM. The code following line 3586 will free the txn and return ENOMEM. This will cause my code to call mdb_txn_abort, which will access the freed memory and call free again. Please ask if more details are needed. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs December 2020