https://bugs.openldap.org/show_bug.cgi?id=10396
Issue ID: 10396
Summary: LMDB: another issue with sorted duplicate DBs and
cursor delete
Product: LMDB
Version: 0.9.19
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
In mdb_cursor_del0, in the second "Adjust other cursors" section (after
mdb_rebalance was called), in these lines
if (m3->mc_xcursor && !(m3->mc_flags & C_EOF)) {
MDB_node *node = NODEPTR(m3->mc_pg[m3->mc_top],
m3->mc_ki[m3->mc_top]);
The node being referenced should be using mc->mc_top, not m3->mc_top. Most of
the time these will be identical, but sometimes due to rebalancing, the mc
cursor may be popped below its stack top when calling here.
This bug was introduced for ITS#8406 in commit
37081325f7356587c5e6ce4c1f36c3b303fa718c on 2016-04-18.
--
You are receiving this mail because:
You are on the CC list for the issue.
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.
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.
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.
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.
https://bugs.openldap.org/show_bug.cgi?id=10428
Issue ID: 10428
Summary: Make larger key sizes available at compile time
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: marlowsd(a)gmail.com
Target Milestone: ---
I discovered that I can increase the key size to 1982 bytes with the following
patch
```
***************
*** 1053,1059 ****
#define METADATA(p) ((void *)((char *)(p) + PAGEHDRSZ))
/** ITS#7713, change PAGEBASE to handle 65536 byte pages */
! #define PAGEBASE ((MDB_DEVEL) ? PAGEHDRSZ : 0)
/** Number of nodes on a page */
#define NUMKEYS(p) ((MP_LOWER(p) - (PAGEHDRSZ-PAGEBASE)) >> 1)
--- 1054,1061 ----
#define METADATA(p) ((void *)((char *)(p) + PAGEHDRSZ))
/** ITS#7713, change PAGEBASE to handle 65536 byte pages */
! #define PAGEBASE PAGEHDRSZ
! // #define PAGEBASE ((MDB_DEVEL) ? PAGEHDRSZ : 0)
/** Number of nodes on a page */
#define NUMKEYS(p) ((MP_LOWER(p) - (PAGEHDRSZ-PAGEBASE)) >> 1)
```
and then passing `-DMDB_MAXKEYSIZE=0` at compile time. I didn't want to use
`MDB_DEVEL` because this is for a production use case.
Is this feature ready to be widely used? If so, could it be given a
compile-time (or run-time) flag please?
Background: this is for Glean
(https://github.com/facebookincubator/Glean/pull/663), this page explains our
DB structure https://glean.software/docs/implementation/db/.
--
You are receiving this mail because:
You are on the CC list for the issue.
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.
https://bugs.openldap.org/show_bug.cgi?id=7392
Ondřej Kuzník <ondra(a)mistotebe.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |SUSPENDED
Target Milestone|2.7.0 |---
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10426
Issue ID: 10426
Summary: liblber: ber_get_stringbvl integer overflow enables
heap buffer overflow via {M} parsing (32-bit builds)
Product: OpenLDAP
Version: 2.6.10
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: lukas(a)artiphishell.com
Target Milestone: ---
Created attachment 1105
--> https://bugs.openldap.org/attachment.cgi?id=1105&action=edit
build.sh
## Issue description
Vulnerable location: `libraries/liblber/decode.c` in `ber_get_stringbvl()`
Root cause: in the first pass that counts elements, `tot_size += siz` is
performed with `ber_len_t` and no overflow check. On 32-bit builds, a large BER
sequence (e.g., SearchRequest attributes parsed via `{M}`) wraps `tot_size`.
The allocation uses the wrapped value (`ber_memalloc_x(tot_size + siz, ...)`),
producing an undersized buffer. The second pass then writes `i` elements into
the vector (BvOff mode for `{M}`), advancing `tot_size` by `siz` and storing
`struct berval` at `res.bo + tot_size`, which overruns the allocation.
Call path observed in the ASAN trace:
`slapd` -> `do_search` (`servers/slapd/search.c:145`, `ber_scanf("{M}}")`) ->
`ber_scanf` (`libraries/liblber/decode.c:815`) -> `ber_get_stringbvl`
(`libraries/liblber/decode.c:471`) -> heap buffer overflow.
## Reproduction Steps
Build instructions:
```bash
mkdir /tmp/openldap-ber-get-stringbvl-overflow
cd /tmp/openldap-ber-get-stringbvl-overflow
# create the following files in this directory
chmod +x build.sh poc.sh
git clone https://github.com/openldap/openldap
./build.sh ./openldap
# Run the PoC
./poc.sh
```
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10403
Issue ID: 10403
Summary: Add a configuration directive that uses the OpenSSL
CONF API to allow openldap config files to set any
configuration supported by that API, and to get new
OpenSSL configuration capabilities through that API
with no changes in openldap.
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: stephen.wall(a)redcom.com
Target Milestone: ---
Created attachment 1090
--> https://bugs.openldap.org/attachment.cgi?id=1090&action=edit
Add a configuration directive that uses the OpenSSL CONF API to allow openldap
config files to set any configuration supported by that API, and to get new
OpenSSL configuration capabilities through th
I am submitting a patch to create a new directive for OpenLDAP config files
that uses the OpenSSL SSL_CONF API to allow configuration of any aspect of
OpenSSL that the API supports without adding specific directives to OpenLDAP
for them. When OpenSSL extends that API, all versions of OpenLDAP with thie
patch will also support those extensions with no additional code.
--
You are receiving this mail because:
You are on the CC list for the issue.