openldap-bugs October 2022

openldap-bugs@openldap.org

1 participants
101 discussions

[Issue 9460] New: Drop support for OpenSSL older than 1.1.1
by openldap-its＠openldap.org 11 Apr '23

11 Apr '23

https://bugs.openldap.org/show_bug.cgi?id=9460 Issue ID: 9460 Summary: Drop support for OpenSSL older than 1.1.1 Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- OpenSSL no longer supports the 1.0.2 series and specifically notes it should not be used: "All older versions (including 1.1.0, 1.0.2, 1.0.0 and 0.9.8) are now out of support and should not be used." Currently configure checks for 1.0.2 or higher. OpenSSL 1.1.1 is supported through 11 Sep 2023. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9496] New: Some writes missing from database
by openldap-its＠openldap.org 15 Mar '23

15 Mar '23

https://bugs.openldap.org/show_bug.cgi?id=9496 Issue ID: 9496 Summary: Some writes missing from database Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: igfoo(a)github.com Target Milestone: --- With the attached test program, some of my database writes appear not to actually be written to the database. For example, a run may look like this: $ ./run.sh All done. All finished 1802 test.txt foo_200 is missing bar_200 is missing foo_404 is missing bar_404 is missing foo_407 is missing bar_407 is missing The script that I am using to run the program is below. This is using mdb.master 52bc29ee2efccf09c650598635cd42a50b6ecffe on Linux, with an ext4 filesystem. Is this an LMDB bug, or is there a bug in my code? Thanks Ian #!/bin/sh set -e if ! [ -d lmdb ] then rm -rf lmdb git clone https://github.com/LMDB/lmdb.git INSTALL_DIR="`pwd`/inst" cd lmdb/libraries/liblmdb make install prefix="$INSTALL_DIR" cd ../../.. fi gcc -Wall -Werror -Iinst/include loop.c inst/lib/liblmdb.a -o loop -pthread rm -f test.db test.db-lock ./loop echo "All finished" mdb_dump -np test.db > test.txt wc -l test.txt for i in `seq 100 999` do if ! grep -q "foo_$i" test.txt then echo "foo_$i is missing" fi if ! grep -q "bar_$i" test.txt then echo "bar_$i is missing" fi done -- You are receiving this mail because: You are on the CC list for the issue.

1 16

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

[Issue 9937] New: slapd buffer overflow in put_simple_filter()
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9937 Issue ID: 9937 Summary: slapd buffer overflow in put_simple_filter() 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: --- Running this results in heap buffer overflow. ./servers/slapd/slapd -T c -a= SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/juhee/project/foxfuzz/programs/network/openldap-test/servers/slapd/slap d+0x726702) Shadow bytes around the buggy address: 0x0c047fffcb10: fa fa 00 07 fa fa 00 00 fa fa 03 fa fa fa 00 05 0x0c047fffcb20: fa fa 02 fa fa fa 02 fa fa fa 03 fa fa fa 07 fa 0x0c047fffcb30: fa fa 02 fa fa fa 03 fa fa fa 06 fa fa fa 00 03 0x0c047fffcb40: fa fa 00 06 fa fa 00 02 fa fa 00 01 fa fa 00 04 0x0c047fffcb50: fa fa 00 00 fa fa 00 fa fa fa 00 02 fa fa 02 fa =>0x0c047fffcb60: fa[fa]02 fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fffcb70: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fffcb80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fffcb90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fffcba0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fffcbb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==2262407==ABORTING Breakpoint 1, 0x00005555556ca320 in __asan_report_load1 () gdb-peda$ bt #0 0x00005555556ca320 in __asan_report_load1 () #1 0x0000555555c7a703 in put_simple_filter () #2 0x0000555555c7a309 in ldap_pvt_put_filter () #3 0x000055555588ca2b in str2filter_x () #4 0x000055555588ced4 in str2filter () #5 0x0000555555a31b61 in slap_tool_init () #6 0x0000555555a2e34d in slapcat () #7 0x0000555555708e1f in main () #8 0x00007ffff78cc083 in __libc_start_main (main=0x555555706ef0 <main>, argc=0x4, argv=0x7fffffffdfc8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffdfb8) at ../csu/libc-start.c:308 #9 0x000055555561011e in _start () -- 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
8
9
10
11
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2022