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=10345
Issue ID: 10345
Summary: Potential memory leak in function rbac_create_session
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: alexguo1023(a)gmail.com
Target Milestone: ---
In `rbac_create_session`, we have the following code:
```c
if ( rc < 0 ) {
rs->sr_err = LDAP_OTHER;
rs->sr_text = "internal error";
} else {
(void)ber_flatten( ber, &rs->sr_rspdata );
rs->sr_rspoid = ch_strdup( slap_EXOP_CREATE_SESSION.bv_val ); // first
rs->sr_err = LDAP_SUCCESS;
}
ber_free_buf(ber);
done:;
// always put the OID in the response:
rs->sr_rspoid = ch_strdup( slap_EXOP_CREATE_SESSION.bv_val ); //second
```
The second `ch_strdup` at the `done` label overwrites `rs->sr_rspoid` without
freeing the previous string, resulting in a memory leak.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10344
Issue ID: 10344
Summary: Potential memory leak in function
firstComponentNormalize and objectClassPretty.
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: alexguo1023(a)gmail.com
Target Milestone: ---
Created attachment 1071
--> https://bugs.openldap.org/attachment.cgi?id=1071&action=edit
Patch: Ensure the first argument passed to `ber_dupbv_x` is not `NULL`.
In `firstComponentNormalize`, the code calls `ber_dupbv_x` but ignores its
return value.
```c
ber_dupbv_x(normalized, val, ctx);
```
When `normalized` is `NULL`, `ber_dupbv_x` allocates a new `struct berval` and
returns it; failing to capture that pointer means we lose ownership and leak
the allocation. The same issue arises in `objectClassPretty`. We should follow
the pattern in function `hexNormalize`, which asserts that its `normalized`
argument is non-NULL before use:
```c
assert(normalized != NULL);
```
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10343
Issue ID: 10343
Summary: Potential Memory Leak in function
slap_uuidstr_from_normalized
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: alexguo1023(a)gmail.com
Target Milestone: ---
Created attachment 1070
--> https://bugs.openldap.org/attachment.cgi?id=1070&action=edit
Patch: Change 1 to -1.
In function slap_uuidstr_from_normalized, the code allocates a new `struct
berval` with
```c
new = (struct berval *)slap_sl_malloc(sizeof(struct berval), ctx);
```
and then attempt to allocate `new->bv_val`. If that second allocation fails, it
sets `rc = 1` and jumps to the `done` cleanup label. However, the cleanup code
only runs when `rc == -1`, so the memory pointed by `new` is never freed,
causing a memory leak.
--
You are receiving this mail because:
You are on the CC list for the issue.
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.
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=10339
Issue ID: 10339
Summary: config_add_internal() use-after-free on failed
cn=config mod
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: ---
If overlay startup/callback fails, bconfig.c:5593 uses the value of ca->argv[1]
despite it being freed already. I guess we can just log the entry's DN.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10303
Issue ID: 10303
Summary: Web site still presents the 2.5 version as LTS
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: elecharny(a)apache.org
Target Milestone: ---
The OpenLDAP web site still indicates that the OpenLDAP 2.5 version is the LTS,
despite a mail announced on August 10, 2024 that starting from January 2025 teh
2.6 branch will be the LTS.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10329
Issue ID: 10329
Summary: Additional issues with pcache, and a test
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: aweits(a)rit.edu
Target Milestone: ---
Created attachment 1062
--> https://bugs.openldap.org/attachment.cgi?id=1062&action=edit
test & patches
Hello again!
Further testing revealed some more issues in pcache [re: ITS#10270]. I've
attached an update to test020-proxycache as well. These are based off the
current git HEAD.
--
You are receiving this mail because:
You are on the CC list for the issue.