openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

[Issue 10357] New: Potential buffer underflow in function config_find_base
by openldap-its＠openldap.org 01 Jul '25

01 Jul '25

https://bugs.openldap.org/show_bug.cgi?id=10357 Issue ID: 10357 Summary: Potential buffer underflow in function config_find_base 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: --- In function `config_find_base`, we have the code: ```c char *c = dn->bv_val+dn->bv_len; for (;*c != ',';c--); ``` In the loop, if the string doesn't contain any commas, `c` will decrement below `dn->bv_val`, causing buffer underflow when `*c` is accessed. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10354] New: Enhancement: Allow tuning of pwdLastSuccess (like authTimestamp)
by openldap-its＠openldap.org 01 Jul '25

01 Jul '25

https://bugs.openldap.org/show_bug.cgi?id=10354 Issue ID: 10354 Summary: Enhancement: Allow tuning of pwdLastSuccess (like authTimestamp) Product: OpenLDAP Version: 2.5.13 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: u.windl(a)ukr.de Target Milestone: --- As I understand it, the function of the lastbind overlay were integrated to slapd core (under different names). While the overly used attribute authTimestamp, slapd uses attribute pwdLastSuccess to record the time of successful bind. So in principle one could activate both at the same time, but the purpose is unclear... Anyway the lastbind overlay allows to configure (among others) the "lastbind-precision", allowing to skip recording of too many successful binds for a while. Unfortunately the slapd core does not offer a comparable thing, so (for example) automated periodic binds (e.g. used for monitoring) may fill a changelog (delta-syncrepl) over time. The proposal is to implement some mechanism of rate limiting for the updates of pwdLastSuccess, or/and allow filtering of DNs that are included/excepted from this mechanism (so automated periodic system accounts may be excepted). -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10329] New: Additional issues with pcache, and a test
by openldap-its＠openldap.org 30 Jun '25

30 Jun '25

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.

1 10

[Issue 10169] New: Add support for token only authentication with otp overlay
by openldap-its＠openldap.org 30 Jun '25

30 Jun '25

https://bugs.openldap.org/show_bug.cgi?id=10169 Issue ID: 10169 Summary: Add support for token only authentication with otp overlay Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Currently the OTP overlay is password + token. It would be nice to be able to configure it so it can run in a token only mode, similar to the slapo-totp overlay in contrib. This would allow us to have a project supported solution and retire that contrib module. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 10308] New: Implement cn=monitor for back-asyncmeta
by openldap-its＠openldap.org 25 Jun '25

25 Jun '25

https://bugs.openldap.org/show_bug.cgi?id=10308 Issue ID: 10308 Summary: Implement cn=monitor for back-asyncmeta Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- Currently back-asyncmeta has no cn=monitor capabilities. It will be useful to implement some, specifically to monitor targets and target connection states. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10304] New: Unable to remove item from directory as part of transaction if it is the last item in that directory
by openldap-its＠openldap.org 24 Jun '25

24 Jun '25

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.

1 3

[Issue 10297] New: LDAP initialization does unnecessary resolution of hostname
by openldap-its＠openldap.org 20 Jun '25

20 Jun '25

https://bugs.openldap.org/show_bug.cgi?id=10297 Issue ID: 10297 Summary: LDAP initialization does unnecessary resolution of hostname Product: OpenLDAP Version: 2.6.8 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: simon.pichugin(a)gmail.com Target Milestone: --- curl --version does try to resolve local hostname, which is usually stored in $HOSTNAME variable. It seems it does that for no good reason. It does not matter whether machine hostname is already FQDN or not, it always try it unconditionally by calling getaddrinfo(3). Every usage of dnf tries to resolve hostname. That is then supressed by myhostname on Fedora, which returns non-helping response. Possibly, the hostname should be fetched from actual network responses. Seen with: openldap-2.6.8-5.fc41.x86_64 Reproducible: Always Steps to Reproduce: 1. dnf install gdb curl 2. gdb --args curl --version 3. (gdb) break getaddrinfo 4. (gdb) run Actual Results: getaddrinfo is called with current hostname, stored into ldap_int_hostname variable. That is used only when ldap client has not configured target server. But this hostname seems fetched always. Expected Results: No network activity happens, unless something is actually requested. This is not the case. Suggestion is to make it lazy initialized. It should be tried only when necessary. This seems to be useful when tlso_session_chkhost in libraries/libldap/tls_o.c is used. It should initialize hostname only once conditions to use it happens. There is a fallback anyway. It should query FQDN only when name_in contains unusable response. Related: https://github.com/systemd/systemd/issues/34897 -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10347] New: Fix a memory leak in function comp_convert_asn_to_ldap
by openldap-its＠openldap.org 14 Jun '25

14 Jun '25

https://bugs.openldap.org/show_bug.cgi?id=10347 Issue ID: 10347 Summary: Fix a memory leak in function comp_convert_asn_to_ldap 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: --- Created attachment 1076 --> https://bugs.openldap.org/attachment.cgi?id=1076&action=edit Patch: Fix a memory leak in function comp_convert_asn_to_ldap In function comp_convert_asn_to_ldap, the bv->bv_val is allocated in 3 places: case BASICTYPE_BOOLEAN: bv->bv_val = (char*)malloc( 5 ); case BASICTYPE_INTEGER: bv->bv_val = (char*)malloc( INITIAL_ATTR_SIZE ); case BASICTYPE_ENUMERATED: bv->bv_val = (char*)malloc( INITIAL_ATTR_SIZE ); When csi->csi_syntax != NULL and csi->csi_syntax->ssyn_pretty != NULL, bv->bv_val is overwriten with bv->bv_val = prettied.bv_val;, causing porential memory leak. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10343] New: Potential Memory Leak in function slap_uuidstr_from_normalized
by openldap-its＠openldap.org 13 Jun '25

13 Jun '25

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.

1 2

[Issue 10344] New: Potential memory leak in function firstComponentNormalize and objectClassPretty.
by openldap-its＠openldap.org 13 Jun '25

13 Jun '25

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.

1 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs