openldap-bugs January 2023

openldap-bugs@openldap.org

1 participants
128 discussions

[Issue 9887] New: Offer to mirror OpenLDAP
by openldap-its＠openldap.org 13 Feb '23

13 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9887 Issue ID: 9887 Summary: Offer to mirror OpenLDAP Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: mirrors(a)jevincanders.net Target Milestone: --- Greetings, We're from Jevin Canders, a hosting company based in New York (servers are in Buffalo). We're wondering if you wanted/needed another US mirror. We're already mirroring other open source projects, including Kali Linux and F-Droid. As of next week (tentatively), our mirror server will have a 20 Gbps pipe to work with, so we'll be able to handle new projects. Let us know if you have any questions, concerns, or requests. Sincerely, Josh Anders and Kevin Croissant JC Mirrors Team -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 9956] New: Please register my company on the support page
by openldap-its＠openldap.org 13 Feb '23

13 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9956 Issue ID: 9956 Summary: Please register my company on the support page Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: sjsong(a)aboutdap.kr Target Milestone: --- Hello. openldap page administrater. Please register my company on the support page. Please contact me if you need additional information. Registration phrase Seojindsa Co., Ltd. (Aboutdap Co., Ltd.)- Korea Provides consultancy, development, training and user support for OpenLDAP software in Korea. URL : seojindsa : www.seojindsa.kr, aboutdap : www.aboutdap.kr thank you. Song. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9912] New: slapd attempting free on address which was not malloced
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9912 Issue ID: 9912 Summary: slapd attempting free on address which was not malloced Product: OpenLDAP Version: 2.6.3 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: kimjuhi96(a)snu.ac.kr Target Milestone: --- Providing following command-line input results in invalid free. ./servers/slapd/slapd -h1 -h1 This issue exists in openldap-2.6.3 and the master branch of git. Environment: - Ubuntu 20.04 - clang-14.0.6 with CFLAGS="-fsanitize=address" Backtrace: ================================================================= ==3323395==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x7ffc8512c238 in thread T0 #0 0x4d0077 (/home/juhee/project/foxfuzz/programs/network/openldap/servers/slapd/slapd+0x4d0077) #1 0xb77152 (/home/juhee/project/foxfuzz/programs/network/openldap/servers/slapd/slapd+0xb77152) #2 0x65ff02 (/home/juhee/project/foxfuzz/programs/network/openldap/servers/slapd/slapd+0x65ff02) #3 0x5168a9 (/home/juhee/project/foxfuzz/programs/network/openldap/servers/slapd/slapd+0x5168a9) #4 0x7ff21bd3c082 (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee) #5 0x42130d (/home/juhee/project/foxfuzz/programs/network/openldap/servers/slapd/slapd+0x42130d) Address 0x7ffc8512c238 is located in stack of thread T0 at offset 10072 in frame #0 0x515fef (/home/juhee/project/foxfuzz/programs/network/openldap/servers/slapd/slapd+0x515fef) This frame has 10 object(s): [32, 36) 'rc' (line 220) [48, 52) 'syslogUser' (line 230) [64, 72) 'waitfds' (line 234) [96, 100) 'level' (line 402) [112, 128) 'opt' (line 432) [144, 148) 'opt393' (line 717) [160, 168) 'errmsg' (line 726) [192, 196) 'buf' (line 778) [208, 336) 'ebuf' (line 798) [368, 496) 'ebuf524' (line 821) <== Memory access at offset 10072 overflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: bad-free (/home/juhee/project/foxfuzz/programs/network/openldap/servers/slapd/slapd+0x4d0077) ==3323395==ABORTING -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9951] New: lloadd can lock up in cn=monitor modify
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9951 Issue ID: 9951 Summary: lloadd can lock up in cn=monitor modify Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- lload_monitor_conn_modify's callers have borrowed the cn=monitor entry from the cache, however it also observes memory management, so if the connection is released and it is the last thread around, it might be responsible for freeing it via epoch_leave(). However freeing it also requires that the connection be removed from cn=monitor and we can deadlock there. A fix is coming. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9913] New: Some lloadd shutdown code doesn't protect memory correctly
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9913 Issue ID: 9913 Summary: Some lloadd shutdown code doesn't protect memory correctly Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- During shutdown, clients_destroy and tier_destroy are called while worker threads might still be alive, therefore they need to participate in memory management. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9907] New: lloadd config/shutdown leaks
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9907 Issue ID: 9907 Summary: lloadd config/shutdown leaks Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- lloadd leaks some memory in cn=config and at shutdown time. Fixes coming -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9906] New: cn=monitor leaks in lloadd
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9906 Issue ID: 9906 Summary: cn=monitor leaks in lloadd 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: --- lloadd registers various types of monitor_subsys_t but currently doesn't tear all parts of them down correctly, leaking memory on server shutdown. Partly down to how back-monitor shutdown works at the moment. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9931] New: test079 broken on MacOSX
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9931 Issue ID: 9931 Summary: test079 broken on MacOSX Product: OpenLDAP Version: 2.5.12 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Strictly-conforming getopt doesn't allow mixing of -options and plain args. All documentation shows that LDAP attributes must be last on the ldapsearch commandline, but the script is putting additional -options after the olmDbConnURI attribute specification, which causes the following -options to be ignored and the search command fails. -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 9991] New: slapd may close a connection twice
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9991 Issue ID: 9991 Summary: slapd may close a connection twice Product: OpenLDAP Version: 2.5.13 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- If slapd is sending an entry to a client, and the client is sending an Unbind request and disconnecting at the same time, send_ldap_ber() will get an error attempting to write on the dead socket. It will then try to call connection_closing() to close the connection. But the frontend may also have gotten a read error on the dead socket, and handled the close there already. By the time send_ldap_ber() acquires the c_mutex and actually calls connection_closing(), the conn struct may have already been assigned to a new connection, and the connection_closing() call will erroneously close an active session. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9940] New: slapadd segfault with -w on a subordinate database
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9940 Issue ID: 9940 Summary: slapadd segfault with -w on a subordinate database 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: dhawes(a)gmail.com Target Milestone: --- I've noticed sporadic segfaults when using slapadd with -w and an LDIF that contains entries on a subordinate database. Removing -w prevents the segfault. I finally had some time to look at this, and the results are odder than I expected. gdb bt: ===== Program terminated with signal SIGSEGV, Segmentation fault. #0 0x000055c2096c1ffd in dnIsSuffix (dn=0x55c20b82c7b8, suffix=0x55c20b749520) at dn.c:1192 1192 if ( d > 1 && !DN_SEPARATOR( dn->bv_val[ d - 1 ] ) ) { (gdb) bt #0 0x000055c2096c1ffd in dnIsSuffix (dn=0x55c20b82c7b8, suffix=0x55c20b749520) at dn.c:1192 #1 0x000055c20974262e in glue_back_select (be=0x7fff683fc5a0, dn=0x55c20b82c7b8) at backglue.c:77 #2 0x000055c209745473 in glue_entry_release_rw (op=0x7fff683fc840, e=0x55c20b82c7a0, rw=0) at backglue.c:927 #3 0x000055c20974824d in overlay_entry_release_ov (op=0x7fff683fc840, e=0x55c20b82c7a0, rw=0, on=0x55c20b78d870) at backover.c:439 #4 0x000055c20974841f in over_entry_release_rw (op=0x7fff683fc840, e=0x55c20b82c7a0, rw=0) at backover.c:483 #5 0x000055c2096b5f94 in be_entry_release_rw (op=0x7fff683fc840, e=0x55c20b82c7a0, rw=0) at backend.c:958 #6 0x000055c209750a3d in slap_tool_update_ctxcsn (progname=0x55c209813b08 "slapadd", sid=18446744073709551615, bvtext=0x7fff683fca20) at slapcommon.c:1015 #7 0x000055c20974e108 in slapadd (argc=11, argv=0x7fff683fce68) at slapadd.c:502 #8 0x000055c209672e56 in main (argc=11, argv=0x7fff683fce68) at main.c:723 (gdb) print *dn $1 = {bv_len = 94291905136528, bv_val = 0x0} ===== dn->bv_val is NULL in this case. This dumb patch prevents the segfault, but does not fix the root issue: ===== --- openldap-2.5.13/servers/slapd/dn.c 2022-07-14 13:09:57.000000000 -0400 +++ openldap-2.5.13-mod/servers/slapd/dn.c 2022-10-25 21:14:13.068933734 -0400 @@ -1188,6 +1188,11 @@ return 0; } + /* dn is null */ + if (dn->bv_val == NULL) { + return 0; + } + /* no rdn separator or escaped rdn separator */ if ( d > 1 && !DN_SEPARATOR( dn->bv_val[ d - 1 ] ) ) { return 0; ===== When I started creating a minimal config for this issue, things got stranger. First, the config: ===== include /usr/local/openldap-2.5.13/etc/openldap/schema/core.schema database mdb suffix "ou=Subordinate,dc=vt,dc=edu" subordinate rootdn "cn=Manager,dc=vt,dc=edu" directory /usr/local/openldap-2.5.13/var/openldap-data/subordinate maxsize 17179869184 index objectClass eq index uid,entryCSN,entryUUID eq database mdb suffix "dc=vt,dc=edu" rootdn "cn=Manager,dc=vt,dc=edu" directory /usr/local/openldap-2.5.13/var/openldap-data/mdb maxsize 17179869184 index objectClass eq index uid,entryCSN,entryUUID eq ===== The LDIF: ===== dn: dc=vt,dc=edu objectClass: dcObject objectClass: organization o: Virginia Tech dc: vt structuralObjectClass: organization entryUUID: e906e392-731f-1034-98c4-c3e119ef52ff creatorsName: cn=Manager,dc=vt,dc=edu createTimestamp: 20150409161915Z entryCSN: 20150409161915.467619Z#000000#000#000000 modifiersName: cn=Manager,dc=vt,dc=edu modifyTimestamp: 20150409161915Z contextCSN: 20221025003300.622285Z#000000#000#000000 dn: ou=Subordinate,dc=vt,dc=edu objectClass: dcObject objectClass: organizationalUnit dc: vt ou: subordinate structuralObjectClass: organizationalUnit entryUUID: 40b0b450-7321-1034-9e54-3f41091a54c5 creatorsName: cn=Manager,dc=vt,dc=edu createTimestamp: 20150409162852Z entryCSN: 20150409162852.039034Z#000000#000#000000 modifiersName: cn=Manager,dc=vt,dc=edu modifyTimestamp: 20150409162852Z ===== Unfortunately, that config and LDIF did not result in a segfault, but I noticed that in my LDIFs that do, there is data after the subordinate entry, but that data is commented out. Adding a small comment did not affect things, but adding a large comment at the end of the LDIF did (4113 characters): ===== #000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a ===== If you remove the 'a' from the end of that comment, there is no segfault. Note that this is sporadic, so I'm running in a loop to detect it: for i in {1..10}; do rm /usr/local/openldap-2.5.13/var/openldap-data/*/*.mdb; slapadd -q -w -b dc=vt,dc=edu -l ./minimal.ldif; done; This also seems to be the case with entries after the subordinate entry that have long attribute values (1027 characters, only tested with dc): ===== dn: ou=1,dc=vt,dc=edu objectClass: dcObject objectClass: organizationalUnit dc: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a ou: 1 structuralObjectClass: organizationalUnit entryUUID: 40b0b450-7321-1034-9e54-3f41091a54c5 creatorsName: cn=Manager,dc=vt,dc=edu createTimestamp: 20150409162852Z entryCSN: 20150409162852.039034Z#000000#000#000000 modifiersName: cn=Manager,dc=vt,dc=edu modifyTimestamp: 20150409162852Z ===== Remove the 'a' from the end of dc, and no segfault. I hope that's enough information to recreate this issue. I'm still looking at it, but I haven't found the root cause yet. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

← Newer
1
...
4
5
6
7
8
9
10
...
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2023