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=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=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.
https://bugs.openldap.org/show_bug.cgi?id=10335
Issue ID: 10335
Summary: [PATCH] ldapsearch: fix handling of -LL in
print_reference()
Product: OpenLDAP
Version: 2.6.9
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: bolek(a)live.com
Target Milestone: ---
Created attachment 1066
--> https://bugs.openldap.org/attachment.cgi?id=1066&action=edit
[PATCH] ldapsearch: fix handling of -LL in print_reference()
I, Boleslaw Ciesielski, hereby place the following modifications to OpenLDAP
Software (and only these modifications) into the public domain. Hence, these
modifications may be freely used and/or redistributed for any purpose with or
without attribution and/or other notice.
The attached patch (against master) fixes a bug in ldapsearch where the -LL (or
-LLL) option is ignored when printing the reference comments in
print_reference().
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10191
Issue ID: 10191
Summary: backend searches should respond to pause requests
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
A long running search will cause mods to cn=config to wait a long time. Search
ops should periodically check for threadpool pause requests.
--
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=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=10304
Issue ID: 10304
Summary: Unable to remove item from directory as part of
transaction if it is the last item in that directory
Product: OpenLDAP
Version: 2.5.13
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: sophie.elliott(a)arcticlake.com
Target Milestone: ---
I am running my ldap server on Debian 11.3, with the mdb backend, using the
backported openldap version 2.5.13. I am not 100% certain if this is an issue
with OpenLDAP or liblmdb, but I have been running tests in the repo and it
looks like the liblmdb tests work fine, so I think it's with OpenLDAP itself.
I have been performing a transaction, and deleting entries from a directory
during this transaction. This works fine if the item that I am deleting isn't
the last entry in its directory, but when it is I get a MDB_NOTFOUND error on
the commit transaction call and the delete doesn't go through. Here is an
excerpt of the logs when this happens:
```
67a64334.14e1fc32 0x766ad2a00700 => index_entry_del( 108,
"accessGroupID=f23de82f-3a1c-4f88-86bb-bb07f9a0992d,o=[COMPANY],ou=accessGroups,dc=local,dc=[COMPANY],dc=com"
)
67a64334.14e21912 0x766ad2a00700 mdb_idl_delete_keys: 6c [62d34624]
67a64334.14e22812 0x766ad2a00700 <= index_entry_del( 108,
"accessGroupID=f23de82f-3a1c-4f88-86bb-bb07f9a0992d,o=[COMPANY],ou=accessGroups,dc=local,dc=[COMPANY],dc=com"
) success
67a64334.14e23a91 0x766ad2a00700 mdb_delete: txn_commit failed: MDB_NOTFOUND:
No matching key/data pair found (-30798)
```
Please let me know if I should submit this issue elsewhere, or if this is
something that has already been fixed in a more recent version. I'm also happy
to provide more details if necessary. Thank you!
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10258
Issue ID: 10258
Summary: test050 failure: connection_close race?
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: ---
Created attachment 1032
--> https://bugs.openldap.org/attachment.cgi?id=1032&action=edit
tail of slapd log
Running test050 repeatedly, the slapd managed to get itself into an apparent
inconsistency in the connections structure. The logs suggest that there might
be a race closing the connection. Unfortunately the sanitiser didn't initiate a
core dump in this case.
--
You are receiving this mail because:
You are on the CC list for the issue.
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.