- openldap-bugs - openldap.org

[Issue 10362] New: Normalised value confusions in replication
by openldap-its＠openldap.org 01 Jul '25

01 Jul '25

https://bugs.openldap.org/show_bug.cgi?id=10362 Issue ID: 10362 Summary: Normalised value confusions in replication 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: --- A lot of code expects a_nvals state to be consistent across modifies and multiple instances of the same attribute (with asserts to that effect), but replication doesn't seem to obey this: Add this assert into syncrepl_diff_entry()[0] : assert( ( old->a_nvals == NULL ) == ( new->a_nvals == NULL ) ); if ( old->a_nvals ) assert( ( old->a_nvals == old->a_vals ) == ( new->a_nvals == new->a_vals ) ); You'll see many tests fail this, the first of which is test043. [0]. https://git.openldap.org/openldap/openldap/-/blob/14d47146b0442df85bd949b21… -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 10360] New: delta-sync can apply old mods
by openldap-its＠openldap.org 01 Jul '25

01 Jul '25

https://bugs.openldap.org/show_bug.cgi?id=10360 Issue ID: 10360 Summary: delta-sync can apply old mods Product: OpenLDAP Version: 2.6.9 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- This might be related to #10358, but not sure. In delta MPR, if an older mod is received on an entry after a newer mod has already been applied by a local user, the older mod is applied and the newer mod is lost. The incoming replication ops are checked for freshness by check_csn_age() but that only checks the incoming cookieCSN against contextCSNs of the same SID. I.e., that check only prevents duplicate mods being replicated multiple times from the same remote provider. If check_csn_age() passes, then syncrepl_message_to_op() is invoked which just applies the mod. It doesn't check the mod or cookieCSN against the entry's current entryCSN. The code in syncrepl_op_mod() performs the checks we need. The code just needs to be pulled into a new function so it can be used in both places. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10359] New: delta-MPR uses logbase for more than it documents
by openldap-its＠openldap.org 01 Jul '25

01 Jul '25

https://bugs.openldap.org/show_bug.cgi?id=10359 Issue ID: 10359 Summary: delta-MPR uses logbase for more than it documents 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: --- syncrepl logbase=<dn> is used not just for a syncrepl session (documented) but also for internal searches when it comes to delta-MPR conflict resolution. This is not documented so an admin doesn't know that the local accesslog DB needs to exist and have the same suffix. Either the documentation needs updating or a new configuration item needs to be added to allow an accesslog DB with a different suffix locally. -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 10358] New: syncrepl can revert an entry's CSN
by openldap-its＠openldap.org 01 Jul '25

01 Jul '25

https://bugs.openldap.org/show_bug.cgi?id=10358 Issue ID: 10358 Summary: syncrepl can revert an entry's CSN 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 1080 --> https://bugs.openldap.org/attachment.cgi?id=1080&action=edit Debug log of an instance of this happening There is a sequence of operations which can force a MPR node to apply changes out of order (essentially reverting an operation). Currently investigating which part of the code that should have prevented this has let it slip. A sample log showing how this happened is attached. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10365] New: OOM during replication with a lot of updates
by openldap-its＠openldap.org 01 Jul '25

01 Jul '25

https://bugs.openldap.org/show_bug.cgi?id=10365 Issue ID: 10365 Summary: OOM during replication with a lot of updates Product: OpenLDAP Version: 2.6.10 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: elecharny(a)apache.org Target Milestone: --- When applying millions of updates on a huge database (30M entries), the server can crash with an out of memory. What happens is that the replication client does not process the incoming updates fast enough, syncprov accumulate the changes in memory up to the point it crashes. The clear workaround: use more memory on the server. Context: the replication mode used is delta-syncrepl, 2 servers, MMR , with MDB and accesslog. My assumption is that it would be valuable to benefit from the fact that we know when the socket is ready for write to actually push data to the replica, which means we can use the changes stored in accesslog and not in memory, while keeping a state of replication. I assume it's a huge change in the way it currently works. There is no urgency, considering it's quite a specific use case, and it would be way faster to slapmodify the changes on a stopped base, then copy the content to the replica, then restart everything. -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 10361] New: lapo-auditlog: Add olcAuditLogNonBlocking to avoid blocking when logging to named pipes
by openldap-its＠openldap.org 01 Jul '25

01 Jul '25

https://bugs.openldap.org/show_bug.cgi?id=10361 Issue ID: 10361 Summary: lapo-auditlog: Add olcAuditLogNonBlocking to avoid blocking when logging to named pipes Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: a.cudbardb(a)freeradius.org Target Milestone: --- Created attachment 1081 --> https://bugs.openldap.org/attachment.cgi?id=1081&action=edit Patch adding olcAuditlogNonBlocking and a tests for slapo-auditlog The default behaviour of fopen() when called on a named pipe which does not have any reader, is to block, until a reader opens the pipe. This in turn blocks slapo-auditlog when it attempts to write output, and prevents slapd processing requests. Depending on how critical the audit log is, it may be preferable to discard audit log output and continue processing requests if there's no reader available which olcAuditLogNonBlocking: TRUE allows. For clarity the call to fopen() is removed and replaced with open()/fdopen(), allowing us to specify O_* flags as opposed to using fopen() OR open()/fdopen() depending on whether we should block. 0666 are the base permissions used by fopen() when files are created. There were no tests for slapo-auditlog, so a small test suite that tests both the basic behaviour, and blocking/non-blocking writes. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10356] New: Openldap -> Chasing the referral is not proceeding further after 3 referrals
by openldap-its＠openldap.org 01 Jul '25

01 Jul '25

https://bugs.openldap.org/show_bug.cgi?id=10356 Issue ID: 10356 Summary: Openldap -> Chasing the referral is not proceeding further after 3 referrals Product: OpenLDAP Version: 2.4.56 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: hharshitha2797(a)gmail.com Target Milestone: --- Hi Team I have an issue with OpenLDAP 2.4.56. Chasing the referral only yields 3 referrals; the user login does not proceed further to other referrals. This issue is seen in CentOS with OPENSSL 3.0 In OpenLDAP 2.1.22, the same is working; here, OpenSSL is not used. Here OPENSSL 3.0 is not used. We can see around 8 referrals here. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10364] New: back-asyncmeta should process a notice-of-disconnect and close the target connection
by openldap-its＠openldap.org 01 Jul '25

01 Jul '25

https://bugs.openldap.org/show_bug.cgi?id=10364 Issue ID: 10364 Summary: back-asyncmeta should process a notice-of-disconnect and close the target connection 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: --- At present, back-asyncmeta discards all unsolicited messages, received on the target connections. It should instead process Notice-of-Disconnection messages and close the connections on which they were received. -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 10363] New: Implement a target connection time-to-live in asyncmeta
by openldap-its＠openldap.org 01 Jul '25

01 Jul '25

https://bugs.openldap.org/show_bug.cgi?id=10363 Issue ID: 10363 Summary: Implement a target connection time-to-live in 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: --- Implement a feature that limits the maximum time before a target connection is reset, even if it is not idle - conn-ttl. To avoid too many target connections timing out at once, a minimum reset interval per target should also be configurable. So, a configuration of: conn-ttl 5s 5s would mean connections have a 5 seconds time-to-live, but a connection should be reset no more frequently that once every 5 seconds per target. This feature was requested by a customer. -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 10355] New: mplay doesn't compile on musl
by openldap-its＠openldap.org 01 Jul '25

01 Jul '25

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.

1 3

[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

[Issue 10348] New: Free ch_malloc-allocated memory in error paths
by openldap-its＠openldap.org 13 Jun '25

13 Jun '25

https://bugs.openldap.org/show_bug.cgi?id=10348 Issue ID: 10348 Summary: Free ch_malloc-allocated memory in error paths 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 1077 --> https://bugs.openldap.org/attachment.cgi?id=1077&action=edit Patch: Relase memory allocated from ch_malloc in 2 error handling branches. In ldap_back_monitor_ops_init and syncrepl_dirsync_message, memory allocated with ch_malloc was not freed when errors occurred. This adds two ch_free calls to ensure proper cleanup in those branches. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10349] New: Free ch_calloc-allocated memory in error paths
by openldap-its＠openldap.org 13 Jun '25

13 Jun '25

https://bugs.openldap.org/show_bug.cgi?id=10349 Issue ID: 10349 Summary: Free ch_calloc-allocated memory in error paths 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 1078 --> https://bugs.openldap.org/attachment.cgi?id=1078&action=edit Free ch_calloc-allocated memory in error paths 1. In aa_operational, bv_allowed and bv_effective are allocated via ch_calloc. If ja == 0 or je == 0, these memory objects are never freed and do not escape the function, causing potential memory leak. 2. In memberof_db_init, the memory allocated by ch_calloc isn’t released on error paths, leading to another potential leak. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10345] New: Potential memory leak in function rbac_create_session
by openldap-its＠openldap.org 13 Jun '25

13 Jun '25

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.

1 2

[Issue 10339] New: config_add_internal() use-after-free on failed cn=config mod
by openldap-its＠openldap.org 12 Jun '25

12 Jun '25

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.

1 3

[Issue 10301] New: Use assertion control in lastbind chaining
by openldap-its＠openldap.org 12 Jun '25

12 Jun '25

https://bugs.openldap.org/show_bug.cgi?id=10301 Issue ID: 10301 Summary: Use assertion control in lastbind chaining 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: --- Take a setup with a bunch of consumers tracking lastbind information and replicating this back from the provider. If a client sends a lot of successful binds to it in a very short window, the changes might not have a chance to replicate down so each of these binds has to trigger a new modification to be forwarded. This results in a lot of DB churn and replication traffic that is actually meaningless (the pwdLastChange values before and after each of the mods will be the same). We probably can't avoid having to send something, but the change we send could have an assertion control attached that lets the provider skip it if pwdLastChange>=new_value, saving on all of the additional processing (and additional useless replication traffic). -- You are receiving this mail because: You are on the CC list for the issue.

1 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs