openldap-bugs October 2024

openldap-bugs@openldap.org

1 participants
122 discussions

[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

[Issue 10253] New: Compile failure with GnuTLS and GCC 14 on 32-bit
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10253 Issue ID: 10253 Summary: Compile failure with GnuTLS and GCC 14 on 32-bit 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: ryan(a)openldap.org Target Milestone: --- Debian bug report: https://bugs.debian.org/1078822 tls_g.c fails to compile on 32-bit platforms with GCC 14: $ gcc --version gcc (Debian 14.2.0-2) 14.2.0 Copyright (C) 2024 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ gcc -dumpmachine i686-linux-gnu $ ./configure --disable-slapd --with-tls=gnutls [...] $ make [...] libtool: compile: cc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c tls_g.c -fPIC -DPIC -o .libs/tls_g.o tls_g.c: In function ‘tlsg_session_pinning’: tls_g.c:971:57: error: passing argument 4 of ‘gnutls_fingerprint’ from incompatible pointer type [-Wincompatible-pointer-types] 971 | keyhash.bv_val, &keyhash.bv_len ) < 0 ) { | ^~~~~~~~~~~~~~~ | | | ber_len_t * {aka long unsigned int *} In file included from tls_g.c:44: /usr/include/gnutls/gnutls.h:2408:32: note: expected ‘size_t *’ {aka ‘unsigned int *’} but argument is of type ‘ber_len_t *’ {aka ‘long unsigned int *’} 2408 | size_t *result_size); | ~~~~~~~~^~~~~~~~~~~ make[2]: *** [Makefile:431: tls_g.lo] Error 1 It looks like the warning has always been emitted since the code was originally committed, but with GCC 14 it became an error. (See <https://gcc.gnu.org/gcc-14/porting_to.html>. The last successful Debian build used GCC 13.) Quoting from the Debian bug report: > ber_len_t is typedef'ed in openldap as unsigned LBER_LEN_T, which is > AC_DEFINED as long. I'm not sure what a static AC_DEFINE in configure.ac > achieves, but that's what we have. On the other side, we have size_t, > which happens to be 32bit. Bummer. I suggest passing the 4th argument as > a temporary variable of type size_t and copying it from/to the target > structure after validating that it fits. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10232] New: assert() at shutdown if a syncrepl session is in refresh
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10232 Issue ID: 10232 Summary: assert() at shutdown if a syncrepl session is in refresh 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: --- When removing the last one, syncinfo_free() checks that there is no active refresh on the backend. This works if operating on olcSyncrepl values because refresh_finished is called where appropriate. However if we're shutting down, this is skipped to make sure we don't schedule a new task and that could lead to an assert failure if there indeed was a refresh in progress (the same probably applies when removing the DB). -- You are receiving this mail because: You are on the CC list for the issue.

1 5

← Newer
1
2
3
4
5
6
7
...
13
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2024