- openldap-bugs - openldap.org

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

05 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 8

[Issue 10352] New: minor: Improve documentation of option "-n" for ldapdelete
by openldap-its＠openldap.org 05 Jun '25

05 Jun '25

https://bugs.openldap.org/show_bug.cgi?id=10352 Issue ID: 10352 Summary: minor: Improve documentation of option "-n" for ldapdelete Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: u.windl(a)ukr.de Target Milestone: --- The documentation for option "-n" in ldapdelete says: "Show what would be done, but don't actually delete entries. Useful for debugging in conjunction with -v." However using option "-n" without option "-v" does not output anything! So the description should be improved, or "-n" should implicitly enable option "-v". Specifically it's not obvious what "Useful for debugging in conjunction with -v." refers to. -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 10351] New: olcSaslHost lacks default value
by openldap-its＠openldap.org 04 Jun '25

04 Jun '25

https://bugs.openldap.org/show_bug.cgi?id=10351 Issue ID: 10351 Summary: olcSaslHost lacks default value Product: OpenLDAP Version: 2.5.13 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: fredrik(a)falk-net.se Target Milestone: --- I'm trying to configure multi-master replication with SASL for cn=config and some other databases. However, I'm running into an issue with GSSAPI/SASL as it also syncs olcSaslHost, which has to be unique to each host in order to work. I'd like if olcSaslHost was left empty then it'd default to the hostname/FQDN of the host running slapd, which would resolve the issue. This issue has been encountered before: https://www.openldap.org/lists/openldap-technical/201508/msg00124.html https://www.openldap.org/lists/openldap-technical/201001/msg00048.html -- You are receiving this mail because: You are on the CC list for the issue.

1 2

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

04 Jun '25

https://bugs.openldap.org/show_bug.cgi?id=6083 --- Comment #4 from Heiko Zelt <hz(a)heikozelt.de> --- 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/ -- You are receiving this mail because: You are on the CC list for the issue.

1 0

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

04 Jun '25

https://bugs.openldap.org/show_bug.cgi?id=6083 --- Comment #3 from Heiko Zelt <hz(a)heikozelt.de> --- I need this feature too. I would like to check if passwords contain only ASCII characters, and a minimum of one uppercase, lowercase, digit and special character. An external password syntax checker would be the most flexible solution. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

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

04 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 1

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

04 Jun '25

https://bugs.openldap.org/show_bug.cgi?id=10350 Issue ID: 10350 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 1079 --> https://bugs.openldap.org/attachment.cgi?id=1079&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 1

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

03 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 0

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

03 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 0

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

31 May '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 6

[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 29 May '25

29 May '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 1

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

28 May '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 0

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

28 May '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 0

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

28 May '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 0

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

28 May '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 0

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

28 May '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 0

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

27 May '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 1

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

27 May '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 2

[Issue 10303] New: Web site still presents the 2.5 version as LTS
by openldap-its＠openldap.org 27 May '25

27 May '25

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.

1 3

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

23 May '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 0

[Issue 10288] New: autoca Attribute olcAutoCAserverClass
by openldap-its＠openldap.org 23 May '25

23 May '25

https://bugs.openldap.org/show_bug.cgi?id=10288 Issue ID: 10288 Summary: autoca Attribute olcAutoCAserverClass Product: OpenLDAP Version: 2.6.9 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: stefan(a)kania-online.de Target Milestone: --- I try to add the autoca overlay with the following ldif: -------------- dn: olcOverlay=autoca,olcDatabase={2}mdb,cn=config objectClass: olcAutoCAConfig objectClass: olcOverlayConfig olcOverlay: autoca olcAutoCADays: 3652 olcAutoCAKeybits: 4096 olcAutoCAserverClass: ipHost olcAutoCAserverDays: 1826 olcAutoCAserverKeybits: 4096 olcAutoCAuserClass: person olcAutoCAuserDays: 365 olcAutoCAuserKeybits: 4096 -------------- ldapadd gives me: adding new entry "olcOverlay=autoca,olcDatabase={2}mdb,cn=config" ldap_add: Other (e.g., implementation specific) error (80) additional info: <olcAutoCAserverClass> handler exited with 1 If I remove the attribute from my ldif, it works. What is wrong with the olcAutoCAserverClass attribute in my ldif? I try to look it up in the admin handbook but I could not find anything. I looked in the source code and found: ------------ { "serverClass", "objectclass", 2, 2, 0, ARG_STRING|ARG_MAGIC|ACA_SRVCLASS, autoca_cf, "( OLcfgOvAt:22.2 NAME 'olcAutoCAserverClass' " "DESC 'ObjectClass of server entries' " "EQUALITY caseIgnoreMatch " "SYNTAX OMsDirectoryString SINGLE-VALUE )", NULL, NULL }, ------------ For me it looks the same as the attribute olcAutoCAuserclass. ------------- { "userClass", "objectclass", 2, 2, 0, ARG_STRING|ARG_MAGIC|ACA_USRCLASS, autoca_cf, "( OLcfgOvAt:22.1 NAME 'olcAutoCAuserClass' " "DESC 'ObjectClass of user entries' " "EQUALITY caseIgnoreMatch " "SYNTAX OMsDirectoryString SINGLE-VALUE )", NULL, NULL }, ------------- -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10336] New: slapd crashes with segfault in mdb_delete.c on non-existent tree part deletion
by openldap-its＠openldap.org 23 May '25

23 May '25

https://bugs.openldap.org/show_bug.cgi?id=10336 Issue ID: 10336 Summary: slapd crashes with segfault in mdb_delete.c on non-existent tree part deletion 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: A.Asemov(a)edpnet.com Target Milestone: --- slapd crashes with segfault in mdb_delete.c on non-existent tree part deletion. Applies to 2.6.7, 2.6.8, 2.6.9 ---------- Prerequisites: ---------- - mdb backend - empty mdb database ---------- Sample reproducer: ---------- ldapdelete -x -H ldap://127.0.0.1 -w "password" -D "cn=MyApplication,dc=Contacts,dc=MyTree" "dc=Contacts,dc=MyTree" ---------- Expected behavior: ---------- ldap_delete: No such object (32) ---------- Actual behavior: ---------- Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00005566507b96e0 in mdb_delete (op=0x7f3f0c002910, rs=0x7f3f19bfd8a0) at ../../../../openldap-epel-2.6.8/openldap-2.6.8/servers/slapd/back-mdb/delete.c:151 ---------- Sample slapd.conf: ---------- include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/openldap.schema allow bind_v2 pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args modulepath /usr/lib64/openldap #moduleload back_shell.la moduleload sssvlv.la moduleload valsort.la TLSCACertificatePath /etc/openldap/certs TLSCertificateFile /etc/<path removed>.crt TLSCertificateKeyFile /etc/<path removed>.key database mdb suffix "dc=Contacts,dc=MyTree" directory "/var/lib/ldap" checkpoint 1024 1 dbnosync maxsize 1048576000 index objectClass eq,pres index ou,cn eq,pres,sub index uidNumber,gidNumber eq,pres index uid eq,pres,sub rootdn "cn=MyApplication,dc=Contacts,dc=MyTree" rootpw "{SSHA}<removed>" access to * by dn="cn=Phone,dc=Contacts,dc=MyTree" read by peername.ip=127.0.0.1 write by anonymous auth by * none overlay sssvlv sssvlv-max 1000 sssvlv-maxperconn 1000 ---------- Sample fix: I am not versed in OpenLDAP code so I can't tell if it's semantically correct. Seems like "e" gets NULL in this piece of code and the piece of code does not verify if "e" is NULL. Adding check for ( e ) makes slapd correctly return ldap_delete: No such object (32) instead of segfaulting. ---------- --- a/servers/slapd/back-mdb/delete.c 2024-05-21 19:19:11.000000000 +0200 +++ b/servers/slapd/back-mdb/delete.c 2025-05-12 14:43:04.652396852 +0200 @@ -148,17 +148,19 @@ "<=- " LDAP_XSTRING(mdb_delete) ": no such object %s\n", op->o_req_dn.bv_val ); - rs->sr_matched = ch_strdup( e->e_dn ); - if ( is_entry_referral( e )) { - BerVarray ref = get_entry_referrals( op, e ); - rs->sr_ref = referral_rewrite( ref, &e->e_name, - &op->o_req_dn, LDAP_SCOPE_DEFAULT ); - ber_bvarray_free( ref ); - } else { - rs->sr_ref = NULL; + if ( e ) { + rs->sr_matched = ch_strdup( e->e_dn ); + if ( is_entry_referral( e )) { + BerVarray ref = get_entry_referrals( op, e ); + rs->sr_ref = referral_rewrite( ref, &e->e_name, + &op->o_req_dn, LDAP_SCOPE_DEFAULT ); + ber_bvarray_free( ref ); + } else { + rs->sr_ref = NULL; + } + mdb_entry_return( op, e ); + e = NULL; } - mdb_entry_return( op, e ); - e = NULL; rs->sr_err = LDAP_REFERRAL; rs->sr_flags = REP_MATCHED_MUSTBEFREED | REP_REF_MUSTBEFREED; -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10290] New: Combination of syncrepl+rwm+syncprov frees the wrong modlist
by openldap-its＠openldap.org 23 May '25

23 May '25

https://bugs.openldap.org/show_bug.cgi?id=10290 Issue ID: 10290 Summary: Combination of syncrepl+rwm+syncprov frees the wrong modlist 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: --- An MPR setup with rwm enabled (regardless of configuration it seems) will crash with the provided modlist being freed twice. This is the sequence of events of what is stored in op->orm_modlist, allocated and freed by whom, replacing the actual pointers to make it easier to track: syncrepl_message_to_op: preparing a modify with 0xoriginal syncrepl_op_modify: old modlist 0xoriginal replacing with 0xsyncrepl_op_modify rwm_op_modify: old modlist 0xsyncrepl_op_modify replacing with 0xrwm_op_modify <modify happens> syncrepl_modify_cb: freeing 0xsyncrepl_op_modify, replacing with 0xoriginal (forgetting 0xrwm_op_modify) rwm_op_rollback: freeing 0xoriginal replacing with 0xsyncrepl_op_modify syncrepl_message_to_op: went in with 0xoriginal, got 0xsyncrepl_op_modify back syncrepl_message_to_op: freeing 0xsyncrepl_op_modify Not sure who is at fault: syncrepl_modify_cb is the one freeing the wrong modlist, but then if backover were to work with an actual "stack", running response callbacks in the opposite order from the request, things would have been ok too. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 7249] slapd segfault with memberof overlay on frontend db
by openldap-its＠openldap.org 23 May '25

23 May '25

https://bugs.openldap.org/show_bug.cgi?id=7249 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10302] New: Double free of idcursor
by openldap-its＠openldap.org 23 May '25

23 May '25

https://bugs.openldap.org/show_bug.cgi?id=10302 Issue ID: 10302 Summary: Double free of idcursor Product: OpenLDAP Version: 2.6.6 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: simon.rupf(a)lzlabs.com Target Milestone: --- Created attachment 1050 --> https://bugs.openldap.org/attachment.cgi?id=1050&action=edit proposed patch, which was created from current master, but also applies to 2.6.6 While switching from Oracle Linux (a RHEL clone) 8 to 9 one of our larger LDAP samples started causing a double free error at the end of the slapadd run. While I can't share the LDIF in question and it didn't consistently cause the issue, only every 5-6 times it ran, I could ran gdb and valgrind on it and suggest the attached patch that resolves that error to re-occur. I validated the patch still applies to the current master branch of openldap, as well as to 2.6.6 on EL9 where we encountered this. The error originally observed was this (commands being run as ldap user): [...] rm -r /var/lib/ldap mkdir /var/lib/ldap slapadd -l /tmp/lz_vault_convert_add.ldif -q -w -n 2 PROXIED attributeDescription "LZVAULTPROFILECOUNT" inserted. PROXIED attributeDescription "LZVAULTGLOBALPROFILECOUNT" inserted. -#################### 100.00% eta none elapsed 03s spd 4.2 M/s Closing DB...double free or corruption (!prev) Under valgrind, the following trace could be observed: valgrind --vgdb=full --leak-check=full --show-leak-kinds=all --track-origins=yes slapadd -l /tmp/lz_vault_convert_add.ldif -q -w -n 2 ==502== Memcheck, a memory error detector ==502== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al. ==502== Using Valgrind-3.23.0 and LibVEX; rerun with -h for copyright info ==502== Command: slapadd -l /tmp/lz_vault_convert_add.ldif -q -w -n 2 ==502== PROXIED attributeDescription "LZVAULTPROFILECOUNT" inserted. PROXIED attributeDescription "LZVAULTGLOBALPROFILECOUNT" inserted. ==502== Invalid read of size 8 ==502== at 0x1E65A9: mdb_cursor_close (mdb.c:7764) ==502== by 0x1F71B8: UnknownInlinedFun (tools.c:202) ==502== by 0x1F71B8: mdb_tool_entry_close (tools.c:152) ==502== by 0x1D8291: slapadd (slapadd.c:511) ==502== by 0x1348C6: main (main.c:540) ==502== Address 0x188c8af8 is 8 bytes inside a block of size 392 free'd ==502== at 0x4847B4C: free (vg_replace_malloc.c:989) ==502== by 0x22CEFE: mdb_cursors_close.isra.0 (mdb.c:2638) ==502== by 0x1EBAAE: mdb_txn_commit (mdb.c:3640) ==502== by 0x1F75E2: mdb_tool_entry_modify (tools.c:1066) ==502== by 0x1D9AF9: slap_tool_update_ctxcsn.part.0 (slapcommon.c:1069) ==502== by 0x1D8440: UnknownInlinedFun (slapcommon.c:962) ==502== by 0x1D8440: slapadd (slapadd.c:502) ==502== by 0x1348C6: main (main.c:540) ==502== Block was alloc'd at ==502== at 0x484482F: malloc (vg_replace_malloc.c:446) ==502== by 0x1E8699: mdb_cursor_open (mdb.c:7690) ==502== by 0x1F8C45: mdb_tool_entry_put (tools.c:707) ==502== by 0x1D8150: slapadd (slapadd.c:453) ==502== by 0x1348C6: main (main.c:540) [...] Please advise if I can provide any further diagnostics, while I can still relatively easily reproduce the issue. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10168] New: olcdbindex doesn't cleanup cleanly
by openldap-its＠openldap.org 23 May '25

23 May '25

https://bugs.openldap.org/show_bug.cgi?id=10168 Issue ID: 10168 Summary: olcdbindex doesn't cleanup cleanly 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 you run the following modify against slapd (notice the olcDbMultival data is wrong), slapd aborts in mdb_cf_cleanup->mdb_attr_dbs_open when cleaning up the olcDbIndex changes: dn: olcDatabase={1}mdb,cn=config changetype: modify add: olcDbIndex olcDbIndex: member eq olcDbIndex: memberof eq - add: olcDbMultival olcDbMultival: member,memberOf 5,15 - -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 10299] New: slapacl -u segfaults on nonexistent user
by openldap-its＠openldap.org 23 May '25

23 May '25

https://bugs.openldap.org/show_bug.cgi?id=10299 Issue ID: 10299 Summary: slapacl -u segfaults on nonexistent user Product: OpenLDAP Version: 2.6.9 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: ratness(a)gmail.com Target Milestone: --- Created attachment 1048 --> https://bugs.openldap.org/attachment.cgi?id=1048&action=edit config.ldif 2.6.9, symas-packaged RPMs, Rocky 9. In slapacl, a rootDN user is, as you'd expect, allowed to do anything: # /opt/symas/sbin/slapacl -D 'cn=Manager,dc=example,dc=com' -u -b 'uid=fakeuser,ou=users,dc=example,dc=com' entry/write authcDN: "cn=manager,dc=example,dc=com" write access to entry: ALLOWED But, a user given full-manage rights, segfaults: # /opt/symas/sbin/slapacl -D 'uid=direct,ou=users,dc=example,dc=com' -u -b 'uid=fakeuser,ou=users,dc=example,dc=com' entry/write authcDN: "uid=direct,ou=users,dc=example,dc=com" Segmentation fault (core dumped) Traceback: Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7135888 in mdb_txn_begin (env=0x0, parent=parent@entry=0x0, flags=flags@entry=131072, ret=ret@entry=0x5555557f4940) at ./../../../libraries/liblmdb/mdb.c:2893 2893 flags |= env->me_flags & MDB_WRITEMAP; Missing separate debuginfos, use: dnf debuginfo-install glibc-2.34-60.el9.x86_64 libevent-2.1.12-6.el9.x86_64 sqlite-libs-3.34.1-6.el9_1.x86_64 (gdb) bt #0 0x00007ffff7135888 in mdb_txn_begin (env=0x0, parent=parent@entry=0x0, flags=flags@entry=131072, ret=ret@entry=0x5555557f4940) at ./../../../libraries/liblmdb/mdb.c:2893 #1 0x00007ffff71361a1 in mdb_opinfo_get (op=op@entry=0x7fffffffdce0, mdb=mdb@entry=0x7ffff7048010, rdonly=rdonly@entry=1, moip=moip@entry=0x7fffffffc410) at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/back-mdb/id2entry.c:793 #2 0x00007ffff7136459 in mdb_entry_get (op=0x7fffffffdce0, ndn=0x7fffffffc640, oc=0x5555557a4360, at=0x5555557c3560, rw=0, ent=0x7fffffffc4c8) at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/back-mdb/id2entry.c:620 #3 0x00005555555a77a0 in be_entry_get_rw (e=0x7fffffffc4c8, rw=0, at=0x5555557c3560, oc=0x5555557a4360, ndn=0x7fffffffc640, op=0x7fffffffdce0) at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/backend.c:1438 #4 fe_acl_group (op=0x7fffffffdce0, target=<optimized out>, gr_ndn=0x7fffffffc640, op_ndn=0x7fffffffde10, group_oc=0x5555557a4360, group_at=0x5555557c3560) at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/backend.c:1494 #5 0x000055555559ec5c in backend_group (op=0x7fffffffdce0, target=<optimized out>, gr_ndn=<optimized out>, op_ndn=<optimized out>, group_oc=<optimized out>, group_at=<optimized out>) at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/backend.c:1690 #6 0x00005555555bfbc2 in slap_acl_mask (access=ACL_WRITE, state=0x7fffffffc660, count=1, matches=0x7fffffffcab0, val=<optimized out>, desc=<optimized out>, e=0x7fffffffd910, op=0x7fffffffdce0, mask=<synthetic pointer>, prev=0x0, a=0x5555557c3970) at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/acl.c:1643 #7 slap_access_allowed (op=op@entry=0x7fffffffdce0, e=e@entry=0x7fffffffd910, desc=<optimized out>, val=<optimized out>, access=<optimized out>, state=<optimized out>, maskp=<optimized out>) at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/acl.c:288 #8 0x00005555555c1e2e in fe_access_allowed (op=0x7fffffffdce0, e=0x7fffffffd910, desc=<optimized out>, val=<optimized out>, access=<optimized out>, state=<optimized out>, maskp=0x7fffffffd828) at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/acl.c:352 #9 0x00005555555b7c74 in access_allowed_mask (op=0x7fffffffdce0, e=0x7fffffffd910, desc=0x55555573d540, val=<optimized out>, access=ACL_WRITE, state=0x0, maskp=0x7fffffffd900) at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/acl.c:456 #10 0x0000555555620182 in slapacl (argc=<optimized out>, argv=0x7fffffffe398) at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/slapacl.c:362 #11 0x000055555557658f in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/main.c:540 I could understand it if it was a case of "trying to verify cn/write and not knowing if the user was objectClass=person" but for entry/write I don't see any reason these should be different. -- You are receiving this mail because: You are on the CC list for the issue.

1 14

[Issue 10325] New: Variant uses overlays OID instead of contrib OID (OLcfgOvAt instead of OLcfgCtAt) for configuration attributes
by openldap-its＠openldap.org 23 May '25

23 May '25

https://bugs.openldap.org/show_bug.cgi?id=10325 Issue ID: 10325 Summary: Variant uses overlays OID instead of contrib OID (OLcfgOvAt instead of OLcfgCtAt) for configuration attributes Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- The variant contrib overlay uses the wrong base OID for its attributes, which leads to OID duplication with DDS -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10312] New: olcSubordinate does not accept a 'false' keyword, contrary to documentation
by openldap-its＠openldap.org 23 May '25

23 May '25

https://bugs.openldap.org/show_bug.cgi?id=10312 Issue ID: 10312 Summary: olcSubordinate does not accept a 'false' keyword, contrary to documentation 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: gray(a)nxg.name Target Milestone: --- The slapd-config(5) manpage documents the olcSubordinate keyword as olcSubordinate: [TRUE | FALSE | advertise] If, however, I try to create a database using olcSubordinate: false then slapadd objects with olcSubordinate: value #0: suffix "ou=foo,o=bar": subordinate must be "TRUE" or "advertise". (For the sake of completeness, it might be worth noting in the manpage that the (unsurprising) default is for a search of a superior database _not_ to be propagated to the subordinate one – ie, the presumed behaviour of olcSubordinate:false) -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10229] New: ldap_result, when invoked with MSG_RECEIVED and a timeout value set to 0 (polling), does not return all available messages until it is called again
by openldap-its＠openldap.org 23 May '25

23 May '25

https://bugs.openldap.org/show_bug.cgi?id=10229 Issue ID: 10229 Summary: ldap_result, when invoked with MSG_RECEIVED and a timeout value set to 0 (polling), does not return all available messages until it is called again 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: nivanova(a)symas.com Target Milestone: --- The issue is noticeable when ldap_result is used by the proxy back-ends. It has not affected back-meta behavior, because when a first call is unsuccessful, it retries with a small timeout. back-asyncmeta will also usually call it twice on the same connection from different threads, although this is not a desired behavior. -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 10140] New: Add microsecond timestamp format for local file logging
by openldap-its＠openldap.org 23 May '25

23 May '25

https://bugs.openldap.org/show_bug.cgi?id=10140 Issue ID: 10140 Summary: Add microsecond timestamp format for local file logging Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: gnoe(a)symas.com Target Milestone: --- Add microsecond-level timestamps to local file logging. Format is: "YYYY-mm-ddTHH:MM:SS.ffffffZ" The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Gregory Noe gnoe(a)symas.com. I have not assigned rights and/or interest in this work to any party. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2023 Gregory Noe Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 10020] New: dynlist's @groupOfUniqueNames is considered only for the first configuration line
by openldap-its＠openldap.org 23 May '25

23 May '25

https://bugs.openldap.org/show_bug.cgi?id=10020 Issue ID: 10020 Summary: dynlist's @groupOfUniqueNames is considered only for the first configuration line Product: OpenLDAP Version: 2.5.13 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: msl(a)touk.pl Target Milestone: --- If we consider the following configuration of dynlist: {0}toukPerson labeledURI uniqueMember+memberOf@groupOfUniqueNames {1}groupOfURLs memberURL uniqueMember+dgMemberOf@groupOfUniqueNames The {0} entry will correctly populate the memberOf relatively to static group membership. The {1} entry will produce dgMemberOf with dynamic group membership correctly (based on memberURL query) but it will not populate static entries IF {0} entry in configuration is present. IF I remove {0} from the dynlist configuration - or - remove @groupOfUniqueNames part from this configuration line, then both dynamic and static entries will be populated correctly for {1}. So the effects are as follows on some user entry: if both {0} and {1} are present - {1} produced only dynamic groups: memberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl if both {0} and {1} are present and @groupOfUniqueNames is removed from {0} - {1} produced static+dynamic groups: dgMemberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl If only {1} is present - {1} produced static+dynamic groups: dgMemberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl For completness - if only {0} is present: memberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl I would expect this behavior to be correct for the first case - {0} and {1}. memberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl dgMemberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl -- You are receiving this mail because: You are on the CC list for the issue.

1 14

[Issue 10279] New: add debug notice also to client tools
by openldap-its＠openldap.org 23 May '25

23 May '25

https://bugs.openldap.org/show_bug.cgi?id=10279 Issue ID: 10279 Summary: add debug notice also to client tools Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: rossi.f(a)inwind.it Target Milestone: --- Created attachment 1040 --> https://bugs.openldap.org/attachment.cgi?id=1040&action=edit openldap-2.6.4-debug-notice.patch The command line -d option, when used for debugging, does nothing if openldap was not compiled byth --enable-debug option. For the server part there is a notice to the user regarding this, I propose to add the same also to client tools. Here is attached the simple patch. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10307] New: Regression when searching for nonexistent entries and no access to DB
by openldap-its＠openldap.org 23 May '25

23 May '25

https://bugs.openldap.org/show_bug.cgi?id=10307 Issue ID: 10307 Summary: Regression when searching for nonexistent entries and no access to DB Product: OpenLDAP Version: 2.5.17 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: --- Patch incoming -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10309] New: Handle potential null pointers returned by ber_strdup
by openldap-its＠openldap.org 23 May '25

23 May '25

https://bugs.openldap.org/show_bug.cgi?id=10309 Issue ID: 10309 Summary: Handle potential null pointers returned by ber_strdup Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: safecoding233(a)gmail.com Target Milestone: --- Created attachment 1052 --> https://bugs.openldap.org/attachment.cgi?id=1052&action=edit fix patch I added two null pointer checks for pointers returned by ber_strdup. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10320] New: sigsegv in autogroup
by openldap-its＠openldap.org 23 May '25

23 May '25

https://bugs.openldap.org/show_bug.cgi?id=10320 Issue ID: 10320 Summary: sigsegv in autogroup Product: OpenLDAP Version: 2.6.9 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: sergej+openldap(a)p5n.pp.ru Target Milestone: --- slapd crashes in autogroup overlay on group modification I have few coredumps and can provide more information. This fails on 0x23 address, it may differs but it looks like f->f_un.f_un_complex is not ended with NULL sometimes. Modified group here is not autogroup, just groupOfUniqueNames. Operation is adding uniqueMember. Distro: Archlinux Overlay config: overlay autogroup autogroup-attrset labeledURIObject labeledURI uniqueMember autogroup-memberof-ad memberOf Stack: #0 0x00007e77bf511d7c in autogroup_memberOf_filter (f=f@entry=0x6f2c6d6165742d70, dn=dn@entry=0x7e765c1659f8, memberof_ad=memberof_ad@entry=0x5ac9490c2190) at autogroup.c:1532 #1 0x00007e77bf511dd1 in autogroup_memberOf_filter (f=0x6f2c6d6165742d70, f@entry=0x5ac9495089f0, dn=dn@entry=0x7e765c1659f8, memberof_ad=memberof_ad@entry=0x5ac9490c2190) at autogroup.c:1537 #2 0x00007e77bf511dd1 in autogroup_memberOf_filter (f=0x5ac9495089f0, dn=dn@entry=0x7e765c1659f8, memberof_ad=0x5ac9490c2190) at autogroup.c:1537 #3 0x00007e77bf512538 in autogroup_modify_entry (op=<optimized out>, rs=0x7e7665cf9910) at autogroup.c:1606 #4 0x00005ac946faf432 in overlay_op_walk () #5 0x00005ac946faf5f2 in ?? () #6 0x00005ac946f494cf in fe_op_modify () #7 0x00005ac946f4b623 in do_modify () #8 0x00005ac946f304d7 in ?? () #9 0x00005ac946f30f4b in ?? () #10 0x00007e77c04756e1 in ldap_int_thread_pool_wrapper (xpool=0x5ac949016bc0) at tpool.c:1059 #11 0x00007e77bfe4b70a in start_thread (arg=<optimized out>) at pthread_create.c:448 #12 0x00007e77bfecfaac in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78 (gdb) p *f Cannot access memory at address 0x23 (gdb) up #1 0x000070fe705f3dd1 in autogroup_memberOf_filter (f=0x23, f@entry=0x55d1c45b6310, dn=dn@entry=0x70fd3000c428, memberof_ad=memberof_ad@entry=0x55d1c416a300) at autogroup.c:1537 1537 result = result || autogroup_memberOf_filter( f, dn, memberof_ad ); (gdb) up #2 0x000070fe705f3dd1 in autogroup_memberOf_filter (f=0x55d1c45b6310, f@entry=0x55d1c45b6670, dn=dn@entry=0x70fd3000c428, memberof_ad=memberof_ad@entry=0x55d1c416a300) at autogroup.c:1537 1537 result = result || autogroup_memberOf_filter( f, dn, memberof_ad ); (gdb) p *f->f_un.f_un_complex $5 = {f_choice = 124232868587560, f_un = {f_un_result = 939550768, f_un_desc = 0x70fd38006830, f_un_ava = 0x70fd38006830, f_un_ssa = 0x70fd38006830, f_un_mra = 0x70fd38006830, f_un_complex = 0x70fd38006830}, f_next = 0x23} f_next is 0x23 which is bad address -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 10328] New: Possible multiple free() calls in rewrite_subst_compile()
by openldap-its＠openldap.org 23 May '25

23 May '25

https://bugs.openldap.org/show_bug.cgi?id=10328 Issue ID: 10328 Summary: Possible multiple free() calls in rewrite_subst_compile() Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: gyf161023(a)gmail.com Target Milestone: --- In rewrite_subst_compile() of libraries/librewrite/subst.c line 216 and 222, `subs` and `submatch` array are freed repeatedly on the index `nsub` instead of l, is this what was intended or the `nsub` has some guarantee to be 1 so that we are not freeing anything for second time? -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10323] New: Starttls critical not working on lloadd
by openldap-its＠openldap.org 23 May '25

23 May '25

https://bugs.openldap.org/show_bug.cgi?id=10323 Issue ID: 10323 Summary: Starttls critical not working on lloadd Product: OpenLDAP Version: 2.6.9 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: grichier(a)scaleway.com Target Milestone: --- Hello, Looks like starttls critical not working on lloadd. I have a backend with starttls configure but with bad CN. When I direct query the backend using ldapsearch with option -ZZ, I have the following error: ldap_start_tls: Connect error (-11) additional info: (unknown error code) But when I query the lloadd, which use same backend with olcBkLloadStartTLS to critical. It's work... On a tcpdump I can see the communication between backend and lloadd is not using starttls. (cleartext). But it shouldn't (critical option) cn: {1}ldap://ldap01.example.com olcBkLloadBackendUri: ldap://ldap01.example.com olcBkLloadNumconns: 10 olcBkLloadBindconns: 5 olcBkLloadRetry: 5000 olcBkLloadMaxPendingOps: 50 olcBkLloadMaxPendingConns: 10 olcBkLloadWeight: 1 olcBkLloadStartTLS: critical -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 10226] New: [PATCH] ldap.conf: some remarks and editorial fixes for this man page
by openldap-its＠openldap.org 23 May '25

23 May '25

https://bugs.openldap.org/show_bug.cgi?id=10226 Issue ID: 10226 Summary: [PATCH] ldap.conf: some remarks and editorial fixes for this man page Product: OpenLDAP Version: unspecified Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: bjarniig(a)vortex.is Target Milestone: --- Created attachment 1020 --> https://bugs.openldap.org/attachment.cgi?id=1020&action=edit Remarks and editotiral fixes for the manual ldap.conf.5 Version 2.6.8 is not named on the webpage when entering an issue. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10327] New: Adding syncprov to cn=config can lock up server
by openldap-its＠openldap.org 23 May '25

23 May '25

https://bugs.openldap.org/show_bug.cgi?id=10327 Issue ID: 10327 Summary: Adding syncprov to cn=config can lock up server Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- As reported on openldap-technical[0], adding syncprov to a cn=config DB can lock up the server. This happens when syncprov_db_otask is scheduled by syncprov_db_open. ITS#9045 has already dealt with this for config_back_entry_get, we can relax this description and allow a config_back_search do the same. Even though it is technically on a different thread than the main modification, AFAIK it is still the only one running as the server is paused and the main modification is paused waiting for it? [0]. https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/… -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10331] New: slap* tools should be a little more helpful as to which command line option was invalid
by openldap-its＠openldap.org 23 May '25

23 May '25

https://bugs.openldap.org/show_bug.cgi?id=10331 Issue ID: 10331 Summary: slap* tools should be a little more helpful as to which command line option was invalid 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: --- Also why where appropriate. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10270] New: Issues with pcache when refresh/persistPcache used
by openldap-its＠openldap.org 23 May '25

23 May '25

https://bugs.openldap.org/show_bug.cgi?id=10270 Issue ID: 10270 Summary: Issues with pcache when refresh/persistPcache used Product: OpenLDAP Version: 2.5.18 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: --- Greetings, OpenLDAP-folk. We've been running with the pcache overlay in 2.5.18 with both query refresh and pcachePersist for a bit and have observed some oddities: 1.) Negative queries don't get refreshed 2.) Queries don't seem to be persisted These behaviors are all exhibited from the current git version as well - code/patches below for clarity of communication: Thanks! Andy commit c0b4fe92c8df746c0e6a777f93f1687135114eb9 Author: Andrew Elble <aweits(a)rit.edu> Date: Fri Oct 11 08:43:47 2024 -0400 negative cache entries are not loaded when pcachePersist is on diff --git a/servers/slapd/overlays/pcache.c b/servers/slapd/overlays/pcache.c index 9ef78fd6bf43..9fd72e6d7261 100644 --- a/servers/slapd/overlays/pcache.c +++ b/servers/slapd/overlays/pcache.c @@ -802,7 +802,11 @@ url2query( goto error; } - cq = add_query( op, qm, &query, qt, PC_POSITIVE, 0 ); + if (BER_BVISNULL( &uuid )) { + cq = add_query( op, qm, &query, qt, PC_NEGATIVE, 0 ); + } else { + cq = add_query( op, qm, &query, qt, PC_POSITIVE, 0 ); + } if ( cq != NULL ) { cq->expiry_time = expiry_time; cq->refresh_time = refresh_time; commit 8f7b50dfcec69fa01f8cf0a4b77f3dee8ef9f0f6 Author: Andrew Elble <aweits(a)rit.edu> Date: Fri Oct 11 08:38:36 2024 -0400 queries with ttr/x-refresh are not loaded when pcachePersist is on diff --git a/servers/slapd/overlays/pcache.c b/servers/slapd/overlays/pcache.c index 40c1f9673776..9ef78fd6bf43 100644 --- a/servers/slapd/overlays/pcache.c +++ b/servers/slapd/overlays/pcache.c @@ -749,7 +749,7 @@ url2query( } } - if ( got != GOT_ALL ) { + if ( (got & GOT_ALL) != GOT_ALL) { rc = 1; goto error; } commit c7e52c90192a43876d40b9776a58db951d27937c Author: Andrew Elble <aweits(a)rit.edu> Date: Fri Oct 11 08:37:13 2024 -0400 ttr was not being applied to negatively cached entries diff --git a/servers/slapd/overlays/pcache.c b/servers/slapd/overlays/pcache.c index 1d6e4ba4edcf..40c1f9673776 100644 --- a/servers/slapd/overlays/pcache.c +++ b/servers/slapd/overlays/pcache.c @@ -1580,6 +1580,8 @@ add_query( case PC_NEGATIVE: ttl = templ->negttl; + if ( templ->ttr ) + ttr = now + templ->ttr; break; case PC_SIZELIMIT: -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9934] New: slapd-config(5) should document how to store certificates for slapd usage
by openldap-its＠openldap.org 23 May '25

23 May '25

https://bugs.openldap.org/show_bug.cgi?id=9934 Issue ID: 9934 Summary: slapd-config(5) should document how to store certificates for slapd usage Product: OpenLDAP Version: 2.5.13 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Commit 7b41feed83b expanded the ability of cn=config to save the certificates used for TLS by slapd directly in the config database. However the documentation for the new parameters was never added to the slapd-config(5) man page. olcTLSCACertificate $ olcTLSCertificate $ olcTLSCertificateKey -- You are receiving this mail because: You are on the CC list for the issue.

1 13

[Issue 10191] New: backend searches should respond to pause requests
by openldap-its＠openldap.org 20 May '25

20 May '25

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.

1 5

[Issue 10337] New: Global TLS options not inherited in context
by openldap-its＠openldap.org 20 May '25

20 May '25

https://bugs.openldap.org/show_bug.cgi?id=10337 Issue ID: 10337 Summary: Global TLS options not inherited in context Product: OpenLDAP Version: 2.6.9 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: remi(a)fedoraproject.org Target Milestone: --- During ldap_create, global options are copied See https://github.com/openldap/openldap/blob/OPENLDAP_REL_ENG_2_6_9/libraries/… /* copy the global options */ AC_MEMCPY(&ld->ld_options, gopts, sizeof(ld->ld_options)); But not the TLS string options See https://github.com/openldap/openldap/blob/OPENLDAP_REL_ENG_2_6_9/libraries/… /* We explicitly inherit the SSL_CTX, don't need the names/paths. Leave * them empty to allow new SSL_CTX's to be created from scratch. */ memset( &ld->ld_options.ldo_tls_info, 0, sizeof( ld->ld_options.ldo_tls_info )); ld->ld_options.ldo_tls_ctx = NULL; Which create inconsistency when trying to generate a newctx For the context See * https://github.com/php/php-src/issues/17776 => why tls_newctx is needed * https://github.com/php/php-src/issues/18529 => regression On PHP side a possible workaround is to do the copyu manually * https://github.com/php/php-src/pull/18547 But should probably be handled at openldap library -- You are receiving this mail because: You are on the CC list for the issue.

1 1

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

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

[Issue 10333] New: Recurring crash in lmdb:mdb_page_alloc()
by openldap-its＠openldap.org 13 May '25

13 May '25

https://bugs.openldap.org/show_bug.cgi?id=10333 Issue ID: 10333 Summary: Recurring crash in lmdb:mdb_page_alloc() Product: LMDB Version: 0.9.29 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: captgol2000(a)yahoo.com Target Milestone: --- Full_Name: Version: 0.9.29 OS: Vendor built Linux based on Ubuntu kernel 4.14.173 mdb_page_alloc (SIGBUS) Number of Events: 610 We have seen a recurring crash in lmdb:mdb_page_alloc() but only in the field with our product. One instance yielded a core in which we confirmed the same stack back trace when examined. It matches the automated backtrace reports we received from field deployments. The lmdb is built from source at version 0.9.29, unchanged from upstream. The operating environment is an embedded Linux appliance with Linux kernel at version "linux-4.14.173-aum-01" and our own application that uses lmdb to store certain data while transactions are in progress. We build everything with gcc 7.3.0 and link with glibc version 2.27. Unfortunately no in-house reproduction has been possible, only a number of matching stack traces from field reports of application crashes. We are working on some system tests to see if can can cause a reproduction. This report is in hopes some others may have seen a similar backtrace to help locate a bug. (gdb) where #0 mdb_page_alloc (num=num@entry=1, mp=mp@entry=0x7ffec216d120, mc=<optimized out>) at mdb.c:2310 #1 0x00007fa2508c764e in mdb_page_new (mc=mc@entry=0x7ffec216d670, flags=flags@entry=1, num=num@entry=1, mp=mp@entry=0x7ffec216d1d0) at mdb.c:7193 #2 0x00007fa2508c7a9b in mdb_page_split (mc=mc@entry=0x7ffec216d670, newkey=newkey@entry=0x7ffec216da70, newdata=newdata@entry=0x7ffec216da50, newpgno=newpgno@entry=18446744073709551615, nflags=0) at mdb.c:8649 #3 0x00007fa2508ca4ee in mdb_cursor_put (mc=0x7ffec216d670, key=0x7ffec216da70, data=0x7ffec216da50, flags=<optimized out>) at mdb.c:6957 #4 0x00007fa2508cc26a in mdb_put (txn=0xb767020, dbi=3, key=0x7ffec216da70, data=0x7ffec216da50, flags=0) at mdb.c:9045 #5 0x00007fa2520a69f4 in XXX_XXX_store::add (this=0x7fa25230ada0 <XXX_x509_validation_s::kv_store_h>, key=0x7ffec216dbc0 "\351\066\030\201\261\223\025\\q\006\204g:\274\241\330\377Ã ", keylen=20, value=0x7ffec216db20 "\002", valuelen=19, flag=<optimized out>, table=XXX_KV_STORE_TABLE_MAIN) at lib/XXX_kv_store.cpp:479 #6 0x00007fa2520a03fa in ?? () #7 0x00007ffec216dc60 in ?? () #8 0x00007ffec216dca8 in ?? () #9 0x00007ffec216dc60 in ?? () #10 0x00007fa2520a2990 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[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 13 May '25

13 May '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 2

[Issue 10332] New: Add support for SSLKEYLOGFILE environment variable to export keys for Wireshark decryption
by openldap-its＠openldap.org 13 May '25

13 May '25

https://bugs.openldap.org/show_bug.cgi?id=10332 Issue ID: 10332 Summary: Add support for SSLKEYLOGFILE environment variable to export keys for Wireshark decryption Product: OpenLDAP Version: 2.6.9 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: michael.osipov(a)siemens.com Target Milestone: --- Please add support to do the following: SSLKEYLOGFILE=keylog.txt ldapsearch -H ldaps://... Other libraries and tools support it to decrypt the TLS traffic with Wireshark for analysis purposes. Curl has a simple, but complete implementation: https://github.com/curl/curl/blob/e008f71f435a39875d86885a96b2eb8968a60fd4/… Maybe it can be reused if license allows that?! -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 7901] slapschema reports error but returns 0
by openldap-its＠openldap.org 13 May '25

13 May '25

https://bugs.openldap.org/show_bug.cgi?id=7901 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |2.6.11 Keywords|needs_review | -- 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