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.
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.
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.
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.
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.
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.
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.
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.
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.
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.