openldap-bugs November 2024

openldap-bugs@openldap.org

1 participants
77 discussions

[Issue 10223] New: tlso_ctx_cipherfree: does not check result of SSL_CTX_set_ciphersuites; can fail with incomplete input provided earlier on in the function
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10223 Issue ID: 10223 Summary: tlso_ctx_cipherfree: does not check result of SSL_CTX_set_ciphersuites; can fail with incomplete input provided earlier on in the function Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: yaneurabeya(a)gmail.com Target Milestone: --- The code on line 366 [1] doesn't check the return value of SSL_CTX_set_ciphersuites(..) before returning from the function, if there's leftover data in the tls13_suites buffer, after processing tls13_suites looking for TLS v1.3 compatible ciphers. OpenSSL doesn't state what specific scenarios could result in a failure with the function, but doing some code inspection [2] it appears that a failure could occur if the value provided in the second parameter (`str` per the manpage [3]) to SSL_CTX_set_ciphersuites(..) is either invalid or an internal memory allocation error occurs. While this isn't necessarily something that can be easily handled, it would be prudent to either ignore the return code explicitly by casting the result to (void) and clearing the error, or handling the OpenSSL error explicitly, using the ERR_* family APIs. This issue was reported by Coverity. 1. https://github.com/openldap/openldap/blob/15edb3b30f2b6a3dbdf77cc42d39466d5… 2. https://github.com/openssl/openssl/blob/5bbdbce856c7ca132e039a24a3156184848… 3. https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_ciphersuites.html -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10248] New: translucent + subordinate regression
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10248 Issue ID: 10248 Summary: translucent + subordinate regression Product: OpenLDAP Version: 2.6.8 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: mike(a)nolta.net Target Milestone: --- Created attachment 1027 --> https://bugs.openldap.org/attachment.cgi?id=1027&action=edit translucent + subordinate regression testcase, formatted for tests/data/regressions/ Hi, Attached please find a testcase for a regression we noticed in a translucent + subordinate slapd configuration. The test works in version 2.4.59, but fails in versions 2.5.5 and 2.6.8. In a nutshell, search results from the subordinate database aren't being returned, even though (judging by the logs) they appear to be found. Thanks, -Mike -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 10233] New: wrong idl intersection
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10233 Issue ID: 10233 Summary: wrong idl intersection Product: OpenLDAP Version: 2.6.8 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: hamano(a)osstech.co.jp Target Milestone: --- The `mdb_idl_intersection()` and `wt_idl_intersection()` functions derived from back-bdb return wrong results. expect: [1, 3] ∩ [2] = [] actual: [1, 3] ∩ [2] = [2] -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10224] New: tlso_session_pinning: return codes from EVP* calls are not checked; can result in crashes or undefined behavior in library
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10224 Issue ID: 10224 Summary: tlso_session_pinning: return codes from EVP* calls are not checked; can result in crashes or undefined behavior in library Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: yaneurabeya(a)gmail.com Target Milestone: --- EVP* calls made in tlso_session_pinning on lines 1189-1191 [1] are not checked when computing the digest which is eventually placed in `keyhash.bv_val` on line [2]. Not checking the EVP* calls can result in undefined behavior, e.g., a library crash with SIGBUS, SIGSEGV, etc, and/or incorrect results when analyzing `keyhash.bv_val` later. The calls should be checked to avoid this scenario. Reported by Coverity. 1. https://github.com/openldap/openldap/blob/15edb3b30f2b6a3dbdf77cc42d39466d5… 2. https://github.com/openldap/openldap/blob/15edb3b30f2b6a3dbdf77cc42d39466d5… -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10219] New: Modify of olcDisabled by removing and adding a value invokes db_open twice
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10219 Issue ID: 10219 Summary: Modify of olcDisabled by removing and adding a value invokes db_open twice Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- A database is enabled by default, and therefore a missing olcDisabled attribute is equivalent to a value of FALSE. This means that currently a modify operation that removes a olcDisabled value will invoke the db_open handler for that database, even if in the same modify operation a value of TRUE is added. A modify operation like this: dn: olcDatabase={1}asyncmeta,cn=config changetype: modify delete: olcDisabled olcDisabled: FALSE - add: olcDisabled olcDisabled: TRUE - will call both db_open and db_close. This could be potentially harmful if the backend type allocates memory on db_open like asyncmeta, for example. It is a rare case, but it is best to fix it just in case. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10227] New: Asyncmeta will not reset a connection if a bind operation fails with LDAP_OTHER, leaving the connection in invalid state
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10227 Issue ID: 10227 Summary: Asyncmeta will not reset a connection if a bind operation fails with LDAP_OTHER, leaving the connection in invalid state Product: OpenLDAP Version: 2.6.8 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- The issue is difficult to reproduce, it can happen under heavy traffic if the target is configured to do a sasl bind with a custom saslmech. In any case, currently asyncmeta only resets the connection of the error is LDAP_UNAVAILABLE, which is incorrect. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10272] New: translucent regression when asking for attributes
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10272 Issue ID: 10272 Summary: translucent regression when asking for attributes Product: OpenLDAP Version: 2.6.8 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: mike(a)nolta.net Target Milestone: --- Hi, Attached please find a translucent overlay regression testcase. The test works in version 2.4.59, but fails in versions 2.5.5 and 2.6.8. Basically, `ldapsearch "employeeType=fulltime"` returns the expected entries, but `ldapsearch "employeeType=fulltime" cn` returns nothing. -Mike -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10155] New: Invalid [aka FUZZ] -F and -T options can core dump ldapsearch
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10155 Issue ID: 10155 Summary: Invalid [aka FUZZ] -F and -T options can core dump ldapsearch Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: doug.leavitt(a)oracle.com Target Milestone: --- A customer reported core dumps in ldapsearch which has been tracked to the the improper use of the -F and -T options. The customer confirmed removing the invalid -F and -T options from their script eliminated the core dumps. The CLI arguments of the failing ldapsearch look like: ldapsearch <good CLI args> -F , -T u <good filter and attr args> The good CLI args include proper uses of -H... -x -D ... -w ... -b ... -s ... The good filter and attrs are also valid CLI inputs. The "bad" args are <sp>-F<sp><COMMA><sp>-T<sp>-u<sp> The -u is also valid but it is consumed as a directory name of -T From man page and code review the the -F argument is supposed to be a valid URL. and the -T argument is supposed to be a valid directory The core file output indicates that main calls free after the search takes place. The location is believed to be here: 1658 if ( urlpre != NULL ) { 1659 if ( def_urlpre != urlpre ) 1660 free( def_urlpre ); <--------- 1661 free( urlpre ); 1662 } ... 1672 tool_exit( ld, rc ); ... This is the first example of the use of -F we have seen so it is unclear how this should be fixed. But code review of ldapsearch.c and common.c exposed a few weaknesses that could help in addressing the issue. Observed weaknesses: The getopt processing code for -T does not check that the arg is actually a directory and fail/error when bad input is provided. Perhaps at least an access(2) check should be performed? It is unclear if -F should only accept file:// URLs. The existing code does not sufficiently check any URL format instead it processes the argument by looking for the first '/' [no error checking] and determine the remainder to be a tmpdir location similar to the -T argument. So, Fuzz input of <COMMA> seems to eventually lead to the core files. It is unclear if -F and -T should be mutually exclusive or not. It seems like the fix to this issue is to add better error checking and to fail on FUZZ inputs. I defer a solution to upstream as it probably requires project direction I lack. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 10237] New: openldap-2.6.8 fails to build with GCC14 with [-Wint-conversion]
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10237 Issue ID: 10237 Summary: openldap-2.6.8 fails to build with GCC14 with [-Wint-conversion] Product: OpenLDAP Version: 2.6.8 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: timo.gurr(a)gmail.com Target Milestone: --- Created attachment 1023 --> https://bugs.openldap.org/attachment.cgi?id=1023&action=edit openldap-2.6.8-build.log With GCC 14 I'm experiencing the following error trying to build openldap 2.6.8: [...] In file included from ../slap.h:55, from search.c:32: search.c: In function 'ldap_back_search': ../../../include/ldap_pvt.h:531:31: error: passing argument 3 of '__gmpz_add' makes pointer from integer without a cast [-Wint-conversion] 531 | mpz_add((mpr), (mpr), (mpv)) | ^~~~~ | | | int search.c:257:9: note: in expansion of macro 'ldap_pvt_mp_add' 257 | ldap_pvt_mp_add( li->li_ops_completed[ SLAP_OP_SEARCH ], 1 ); | ^~~~~~~~~~~~~~~ In file included from ../../../include/ldap_pvt.h:519: /usr/x86_64-pc-linux-gnu/include/gmp.h:633:51: note: expected 'mpz_srcptr' {aka 'const __mpz_struct *'} but argument is of type 'int' 633 | __GMP_DECLSPEC void mpz_add (mpz_ptr, mpz_srcptr, mpz_srcptr); | ^~~~~~~~~~ make[3]: *** [Makefile:331: search.lo] Error 1 make[2]: *** [Makefile:550: .backend] Error 1 make[1]: *** [Makefile:298: all-common] Error 1 make: *** [Makefile:319: all-common] Error 1 This is with GCC 14.1.0, switching to GCC 13.2.0 instead allows the build to succeed, I checked other distributions (already on GCC 14) and git for possible patches but couldn't find anything relevant. Complete build log is attached. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10264] New: libpdap leaks dummy_lr data on NoD processing
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10264 Issue ID: 10264 Summary: libpdap leaks dummy_lr data on NoD processing Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- When a NoD unsolicited response is being processed in try_read1msg, we use the dummy_lr on stack, but data copied onto it is never freed, so we leak it as we return. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2024