- openldap-bugs - openldap.org

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

20 Jun '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 1

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

18 Jun '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 2

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

18 Jun '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 1

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

17 Jun '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 0

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

14 Jun '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 4

[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 10356] New: Openldap -> Chasing the referral is not proceeding further after 3 referrals
by openldap-its＠openldap.org 12 Jun '25

12 Jun '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 1

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

12 Jun '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 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

[Issue 10330] New: TIMEOUT and NETWORK_TIMEOUT not respected when receiving bad data during TLS negotiation
by openldap-its＠openldap.org 12 Jun '25

12 Jun '25

https://bugs.openldap.org/show_bug.cgi?id=10330 Issue ID: 10330 Summary: TIMEOUT and NETWORK_TIMEOUT not respected when receiving bad data during TLS negotiation Product: OpenLDAP Version: 2.6.9 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: michael.kourlas(a)solace.com Target Milestone: --- Created attachment 1063 --> https://bugs.openldap.org/attachment.cgi?id=1063&action=edit Test program This seems related to bug 8047. Steps to reproduce: 1. Setup a netcat server on a host: "nc -l -k -p 636". 2. On a different host, attempt to connect to the host running "nc" as if it were an LDAP server via ldaps: "ldapsearch -o NETWORK_TIMEOUT=5 -o TIMEOUT=5 -H ldaps://<ip>:636". 3. During the 5 second timeout period, switch back to the netcat server and transmit a newline by pressing enter. 4. ldapsearch will hang forever until the TCP connection is closed (e.g. by killing the netcat server). My expectation would be that ldapsearch would exit after 5 seconds, per the NETWORK_TIMEOUT and TIMEOUT options. I'm using the following version of ldapsearch on Fedora 41 (x86-64): > ldapsearch: @(#) $OpenLDAP: ldapsearch 2.6.9 (Mar 27 2025 00:00:00) $ > openldap > (LDAP library: OpenLDAP 20609) This problem is also observable when directly using the OpenLDAP C API. This is more of an issue, since any application using the API could become unresponsive if these timeout values aren't respected. I've attached a short test program which can be used instead of ldapsearch. If I abort the test program while it is stuck in this state, the traceback looks like this: > #0 0x00007f50b7a25811 in __GI___libc_read (fd=3, buf=0x2aaf9ac5, nbytes=3) at ../sysdeps/unix/sysv/linux/read.c:26 > #1 0x00007f50b792f8b9 in sb_debug_read (sbiod=0x2aadf390, buf=0x2aaf9ac5, len=3) > at /usr/src/debug/openldap-2.6.9-1.fc41.x86_64/openldap-2.6.9/libraries/liblber/sockbuf.c:829 > #2 0x00007f50b7b61156 in tlso_bio_read (b=0x2aadf9c0, buf=0x2aaf9ac5 "", len=3) > at /usr/src/debug/openldap-2.6.9-1.fc41.x86_64/openldap-2.6.9/libraries/libldap/tls_o.c:1279 > #3 0x00007f50b7221ea3 in bread_conv (bio=<optimized out>, data=<optimized out>, datal=<optimized out>, readbytes=0x7ffd1cf2e3f0) > at crypto/bio/bio_meth.c:121 > #4 0x00007f50b7226047 in bio_read_intern (b=b@entry=0x2aadf9c0, data=0x2aaf9ac5, data@entry=0x555f3588, dlen=3, dlen@entry=18446744072487067717, > readbytes=readbytes@entry=0x7ffd1cf2e3f0) at crypto/bio/bio_lib.c:285 > #5 0x00007f50b72261db in BIO_read (b=0x2aadf9c0, data=0x555f3588, dlen=-1222483899) at crypto/bio/bio_lib.c:311 > #6 BIO_read (b=b@entry=0x2aadf9c0, data=data@entry=0x2aaf9ac5, dlen=dlen@entry=3) at crypto/bio/bio_lib.c:303 > #7 0x00007f50b783ce03 in tls_default_read_n (rl=0x2aaec1c0, n=5, max=<optimized out>, extend=<optimized out>, clearold=<optimized out>, > readbytes=0x7ffd1cf2e4b8) at ssl/record/methods/tls_common.c:406 > #8 0x00007f50b784151b in tls_get_more_records (rl=0x2aaec1c0) at ssl/record/methods/tls_common.c:583 > #9 0x00007f50b783b8ea in tls_read_record (rl=0x2aaec1c0, rechandle=0x2aaeb600, rversion=0x2aaeb608, type=0x2aaeb60c "", data=0x2aaeb610, > datalen=0x2aaeb620, epoch=0x0, seq_num=0x0) at ssl/record/methods/tls_common.c:1130 > #10 0x00007f50b783969a in ssl3_read_bytes (ssl=<optimized out>, type=22 '\026', recvd_type=0x7ffd1cf2e684 "", buf=0x2aaee480 "\001", len=4, > peek=0, readbytes=0x7ffd1cf2e688) at ssl/record/rec_layer_s3.c:689 > #11 0x00007f50b784f5a7 in tls_get_message_header (s=0x2aaea980, mt=<synthetic pointer>) at ssl/statem/statem_lib.c:1554 > --Type <RET> for more, q to quit, c to continue without paging-- > #12 read_state_machine (s=0x2aaea980) at ssl/statem/statem.c:625 > #13 state_machine (s=<optimized out>, server=0) at ssl/statem/statem.c:479 > #14 0x00007f50b7b615c3 in tlso_session_connect (ld=<optimized out>, sess=0x2aaea980, name_in=<optimized out>) > at /usr/src/debug/openldap-2.6.9-1.fc41.x86_64/openldap-2.6.9/libraries/libldap/tls_o.c:693 > #15 0x00007f50b7b65bf2 in ldap_int_tls_connect (ld=ld@entry=0x2a9b2430, conn=conn@entry=0x2a9b25d0, host=host@entry=0x2a9b2550 "192.168.133.56") > at /usr/src/debug/openldap-2.6.9-1.fc41.x86_64/openldap-2.6.9/libraries/libldap/tls2.c:425 > #16 0x00007f50b7b6636f in ldap_int_tls_start (ld=0x2a9b2430, conn=0x2a9b25d0, srv=<optimized out>) > at /usr/src/debug/openldap-2.6.9-1.fc41.x86_64/openldap-2.6.9/libraries/libldap/tls2.c:1245 > #17 0x00007f50b7b3d4c2 in ldap_int_open_connection (ld=0x2a9b2430, conn=0x2a9b25d0, srv=0x2a9b24d0, async=0) > at /usr/src/debug/openldap-2.6.9-1.fc41.x86_64/openldap-2.6.9/libraries/libldap/open.c:515 > #18 0x00007f50b7b5212d in ldap_new_connection (ld=0x2a9b2430, srvlist=0x2a9b2878, use_ldsb=1, connect=<optimized out>, bind=0x0, m_req=0, m_res=0) > at /usr/src/debug/openldap-2.6.9-1.fc41.x86_64/openldap-2.6.9/libraries/libldap/request.c:491 > #19 0x00007f50b7b3c7b4 in ldap_open_defconn (ld=0x2a9b2430) > at /usr/src/debug/openldap-2.6.9-1.fc41.x86_64/openldap-2.6.9/libraries/libldap/open.c:42 > #20 0x00007f50b7b52ed8 in ldap_send_initial_request (ld=0x2a9b2430, msgtype=96, dn=0x4023a9 "cn=admin,dc=solace,dc=com", ber=0x2a9b2570, msgid=1) > at /usr/src/debug/openldap-2.6.9-1.fc41.x86_64/openldap-2.6.9/libraries/libldap/request.c:131 > #21 0x00007f50b7b429b9 in ldap_sasl_bind (ld=0x2a9b2430, dn=0x4023a9 "cn=admin,dc=solace,dc=com", mechanism=0x0, cred=0x7ffd1cf2eb90, sctrls=0x0, > cctrls=0x0, msgidp=0x7ffd1cf2eb8c) at /usr/src/debug/openldap-2.6.9-1.fc41.x86_64/openldap-2.6.9/libraries/libldap/sasl.c:164 -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 7697] RFE: contrib/slapo-lastbind as an official overlay
by openldap-its＠openldap.org 12 Jun '25

12 Jun '25

https://bugs.openldap.org/show_bug.cgi?id=7697 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |u.windl(a)ukr.de --- Comment #5 from Ondřej Kuzník <ondra(a)mistotebe.net> --- *** Issue 10354 has been marked as a duplicate of this issue. *** -- You are receiving this mail because: You are on the CC list for the issue.

1 0

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

12 Jun '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 1

[Issue 10335] New: [PATCH] ldapsearch: fix handling of -LL in print_reference()
by openldap-its＠openldap.org 12 Jun '25

12 Jun '25

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.

1 2

[Issue 10338] New: constraint overlay rejects empty modifications
by openldap-its＠openldap.org 12 Jun '25

12 Jun '25

https://bugs.openldap.org/show_bug.cgi?id=10338 Issue ID: 10338 Summary: constraint overlay rejects empty modifications Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- If configured even with no rules, a modification with a NULL op->orm_modlist is rejected, despite not being able to break any constraints, e.g.: dn: cn=example changetype: modify # no modifications attached This should at least be configurable. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10346] New: mdb_env_copy2 on a database with a value larger than (2GB-16) results in a corrupt copy
by openldap-its＠openldap.org 10 Jun '25

10 Jun '25

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.

1 4

[Issue 10342] New: Potential Memory Leak in function mdb_txn_begin
by openldap-its＠openldap.org 10 Jun '25

10 Jun '25

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.

1 3

[Issue 10340] New: Potential Buffer Overflow in mdb_rebalance
by openldap-its＠openldap.org 10 Jun '25

10 Jun '25

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.

1 4

[Issue 10341] New: Two potential buffer overruns in function mdb_cmp_cint.
by openldap-its＠openldap.org 10 Jun '25

10 Jun '25

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.

1 3

[Issue 6083] ppolicy should also support invocation of an external password checker
by openldap-its＠openldap.org 10 Jun '25

10 Jun '25

https://bugs.openldap.org/show_bug.cgi?id=6083 --- Comment #6 from Howard Chu <hyc(a)openldap.org> --- (In reply to Heiko Zelt from comment #4) > PS: and I would like to check, if a password is compromised. I already have > an external checker for this. It just needs an interface to OpenLDAP. > Information about compromised passwords and it's importance can be found at > https://haveibeenpwned.com/ To be clear - you should write your own pwdCheckModule that interfaces to whatever you want to talk to. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs