- openldap-bugs - openldap.org

[Issue 9972] New: SSS needs READ instead of SEARCH access
by openldap-its＠openldap.org 27 Feb '23

27 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9972 Issue ID: 9972 Summary: SSS needs READ instead of SEARCH access Product: OpenLDAP Version: 2.6.3 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- I have configured an OpenLDAP 2.6 server with dn: olcDatabase=mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: mdb olcAccess: to dn="cn=bodies,dc=aegee,dc=org" by * search # no problem if this is READ olcAccess: to dn.sub="dc=aegee,dc=org" by * read … dn: olcOverlay=sssvlv,olcDatabase={1}mdb,cn=config objectClass:olcOverlayConfig The content of the tree is available anymously by calling ldapsearch -ZZxH ldap://ldap.aegee.org -b "dc=aegee,dc=org" -s sub . When I modify the call to use SSS: ldapsearch -ZxH ldap://ldap.aegee.org -b "dc=aegee,dc=org" -s sub -E sss=ou:2.5.13.15 it also returns results, but ends with ``` # search result search: 93 result: 50 Insufficient access # numResponses: 3 # numEntries: 2 ``` When I modify above: olcAccess: to dn="cn=bodies,dc=aegee,dc=org" by * read then the access is sufficient. There is no entry called "dn:cn=bodies,dc=aegee,dc=org", or rather the entry shall not be returned on searches and `ldapsearch -ZxH ldap://ldap.aegee.org -b "dc=aegee,dc=org" -s sub` does not return it. These work without a problem: ldapsearch -ZxH ldap://ldap.aegee.org -b "cn=bodies,dc=aegee,dc=org" -s one -E sss=ou:2.5.13.15 ldapsearch -ZxH ldap://ldap.aegee.org -b "cn=bodies,dc=aegee,dc=org" -s sub ldapsearch -ZxH ldap://ldap.aegee.org -b "cn=bodies,dc=aegee,dc=org" -s one This produces Insufficient access: ldapsearch -ZxH ldap://ldap.aegee.org -b "cn=bodies,dc=aegee,dc=org" -s sub -E sss=ou:2.5.13.15 That said client-side-sorting does work without a problem, but server-side sorting requires not only SEARCH, but also READ privileges on dn="cn=bodies,dc=aegee,dc=org". I find this is a bug: SSS requires read-acesss to data, which is not supposed to be returned to the client (dn:cn=bodies,dc=aegee,dc=org). For the additional server-side sorting no additional privileges shall be required, compared to returning the results without server-side-sorting. -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 10009] New: test076 execution failed
by openldap-its＠openldap.org 27 Feb '23

27 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=10009 Issue ID: 10009 Summary: test076 execution failed Product: OpenLDAP Version: 2.6.3 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: test suite Assignee: bugs(a)openldap.org Reporter: 1010881517(a)qq.com Target Milestone: --- openldap-2.6.3test case test076-authid-rewrite failed when I upgrade openssl to openssl3.0 Does anyone have a similar problem? >>>>> 00:27:30 Starting test076-authid-rewrite for mdb... running defines.sh Starting slapd on TCP/IP port 9011... /home/abuild/rpmbuild/BUILD/openldap-2.6.3/openldap-2.6.3/tests Using ldapsearch to check that slapd is running... Checking whether DIGEST-MD5 is supported... Adding schema and database... Using ldapadd to populate the database... Adding olcAuthzRegexp rule for static mapping... Testing ldapwhoami as Manager... ./scripts/test076-authid-rewrite: line 177: 219330 Segmentation fault (core dumped) $LDAPSASLWHOAMI -H $URI1 -Y $MECH -U $ID -w $PASSWD ldapwhoami failed (139)! >>>>> 00:27:33 Failed test076-authid-rewrite for mdb after 3 seconds (exit 139) -- You are receiving this mail because: You are on the CC list for the issue.

2 9

[Issue 10012] New: fcntl called without checking value
by openldap-its＠openldap.org 27 Feb '23

27 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=10012 Issue ID: 10012 Summary: fcntl called without checking value Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: balaev(a)tarantool.org Target Milestone: --- Created attachment 949 --> https://bugs.openldap.org/attachment.cgi?id=949&action=edit patch file ldap_pvt_socket() and ldap_int_socket() calls fcntl without checking value of file descriptor. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10008] New: Makefile does not building DLLs on Cygwin/MSYS2
by openldap-its＠openldap.org 27 Feb '23

27 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=10008 Issue ID: 10008 Summary: Makefile does not building DLLs on Cygwin/MSYS2 Product: LMDB Version: unspecified Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: facboy(a)gmail.com Target Milestone: --- Currently when building on Cygwin/MSYS2 make does not generate DLL files. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 8447] LMDB: Overwriting values in MDB_DUPSORT databases broken
by openldap-its＠openldap.org 25 Feb '23

25 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=8447 --- Comment #3 from nicolas.werner(a)hotmail.de --- I can reproduce this without using any cursors. I am using the lmdb++ header for simplicity (https://github.com/hoytech/lmdbxx), but it also reproduces using the plain C API. Full repro: #include <iostream> #include <stdlib.h> #include "lmdb++.h" #define PROJECT_NAME "mdb-dup-bug" static int compare_state_key(const MDB_val *a, const MDB_val *b) { auto get_skey = [](const MDB_val *v) { std::string_view data(static_cast<const char *>(v->mv_data), v->mv_size); return data.substr(0, data.find(',')); }; return get_skey(a).compare(get_skey(b)); } int main(int argc, char **argv) { if(argc != 1) { std::cout << argv[0] << "takes no arguments.\n"; return 1; } std::cout << "This is project " << PROJECT_NAME << ".\n"; auto env = lmdb::env::create(); env.set_max_dbs(10); char dirname[] = "/tmp/lmdb-bug.XXXXXX"; env.open(mkdtemp(dirname)); lmdb::dbi db; { auto txn = lmdb::txn::begin(env); db = lmdb::dbi::open( txn, std::string("dupsort").c_str(), MDB_CREATE | MDB_DUPSORT); lmdb::dbi_set_dupsort(txn, db, compare_state_key); db.put(txn, "abcd", "ab,cdef"); db.put(txn, "abcd", "a,abc"); txn.commit(); } { auto txn = lmdb::txn::begin(env); std::string_view data; db.get(txn, "abcd", data); std::cout << "Data size: " << data.size() << " expected: 5, data: '" << data << "', expected: 'a,abc'\n"; txn.commit(); } { auto txn = lmdb::txn::begin(env); db.put(txn, "abcd", "a,12"); txn.commit(); } { auto txn = lmdb::txn::begin(env); std::string_view data; db.get(txn, "abcd", data); std::cout << "Data size: " << data.size() << " expected: 4, data: '" << data << "', expected: 'a,12'\n"; txn.commit(); } { auto txn = lmdb::txn::begin(env); db.put(txn, "abcd", "a,x"); txn.commit(); } { auto txn = lmdb::txn::begin(env); std::string_view data; db.get(txn, "abcd", data); std::cout << "Data size: " << data.size() << " expected: 3, data: '" << data << "', expected: 'a,x'\n"; txn.commit(); } return 0; } This prints the following output: This is project mdb-dup-bug. Data size: 5 expected: 5, data: 'a,abc', expected: 'a,abc' Data size: 5 expected: 4, data: 'a,12c', expected: 'a,12' Data size: 5 expected: 3, data: 'a,x2c', expected: 'a,x' Commenting out the first put with the different data-key resolves the issue, but certainly you would expect that replacing a duplicate replaces the size too. Doing explicit delete before the put works around this issue. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 4501] jdbcldap: use of enum reserved work (Java 1.5)
by openldap-its＠openldap.org 18 Feb '23

18 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=4501 --- Comment #5 from Fredrik Roubert <fredrik(a)roubert.name> --- Java 1.5 is no longer sufficient to be able to build this code base using a still supported JDK, so I propose updating the scope of this issue to Java 8 instead and then resolve that with this series of patches: https://git.openldap.org/openldap/jdbcldap/-/merge_requests/6 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[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 10010] New: password/sha2 produces incorrect SHA256
by openldap-its＠openldap.org 13 Feb '23

13 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=10010 Issue ID: 10010 Summary: password/sha2 produces incorrect SHA256 Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: pmenzel+bugs.openldap.org(a)molgen.mpg.de Target Milestone: --- From [Debian BTS report #1030716](https://bugs.debian.org/1030716): Dear Maintainer, we got a report[1] on Ubuntu that the contrib module password/sha2 was producing an incorrect SHA256 hash. It was confirmed for a number of releases (22.04, 22.10 and the upcoming 23.04). I checked and it also happens on current debian/sid: $ slappasswd -s secret -h '{SHA256}' -o module-load=pw-sha2 {SHA256}WIrrpN3OjEVOUf6yrH1j+o+ODuUuNBo979Od4UXnu54= $ echo "{SHA256}$(echo -n secret | openssl dgst -sha256 -binary | openssl enc -base64)" {SHA256}K7gNU3sdo+OL0wNhqoVWhr3g6s1xYv72ol/pe/Unols= The suggested fix was to rebuild just this module with `-fno-strict-aliasing`, and indeed that fixed it in Ubuntu. Other options include: - finding the offending piece of code that is causing this optimization to misbehave - updating the module to use gnutls or openssl, whatever openldap ends up being linked with - not building/shipping this module 1. https://bugs.launchpad.net/bugs/2000817 -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[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 9045] Crashes in cn=config (test050)
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9045 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[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 9955] UTF8bvnormalize() overruns
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9955 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[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

[Issue 9935] New: buffer overflow in UTF8StringValidate
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9935 Issue ID: 9935 Summary: buffer overflow in UTF8StringValidate 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: --- I get a heap buffer overflow running this on the latest openldap on git. Built with CFLAGS="-fsanitize=address" using clang 15. ./servers/slapd/slapd $(python2 -c 'print("-Td \x4c\x3d\xc2\x8c\xf0\xf0")') SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/juhee/project/foxfuzz/programs/network/openldap-ori/servers/slapd/slapd +0x3961ac) Shadow bytes around the buggy address: 0x0c047fffcb00: fa fa 00 06 fa fa 00 00 fa fa 00 07 fa fa 00 00 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[05]fa 0x0c047fffcb60: fa fa 00 00 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 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 ==2202218==ABORTING Stopped reason: SIGABRT __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. gdb-peda$ bt #0 __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x00007ffff78ca859 in __GI_abort () at abort.c:79 #2 0x00005555556eb04f in __sanitizer::Abort () at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_posix_libcdep.cpp:143 #3 0x00005555556e8aac in __sanitizer::Die () at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_termination.cpp:58 #4 0x00005555556c5dda in __asan::ScopedInErrorReport::~ScopedInErrorReport (this=0x7fffffffc4d6, __in_chrg=<optimized out>) at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/asan/asan_report.cpp:192 #5 0x00005555556c6461 in __asan::ReportGenericError (pc=<optimized out>, bp=0x7fffffffd140, sp=0x7fffffffd138, addr=0x602000025af5, is_write=is_write@entry=0x0, access_size=0x1, fatal=0x1, exp=<optimized out>) at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/asan/asan_report.cpp:199 #6 0x00005555556c99d6 in __asan::ReportGenericError (pc=<optimized out>, bp=bp@entry=0x7fffffffd140, sp=sp@entry=0x7fffffffd138, addr=<optimized out>, is_write=is_write@entry=0x0, access_size=access_size@entry=0x1, exp=<optimized out>, fatal=0x1) at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_atomic_clang.h:74 #7 0x00005555556ca34c in __asan::__asan_report_load1 (addr=<optimized out>) at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:118 #8 0x00005555558ea1ad in UTF8StringValidate () #9 0x000055555581e5a7 in LDAPRDN_rewrite () #10 0x000055555581d059 in LDAPDN_rewrite () #11 0x0000555555820f7f in dnPrettyNormal () #12 0x0000555555a37d1d in slapdn () #13 0x000055555570901f in main () #14 0x00007ffff78cc083 in __libc_start_main (main=0x555555706ef0 <main>, argc=0x3, argv=0x7fffffffdfd8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffdfc8) at ../csu/libc-start.c:308 #15 0x000055555561011e in _start () at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_internal_defs.h:397 -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9930] New: test050 deadlock on BSD OSes
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9930 Issue ID: 9930 Summary: test050 deadlock on BSD OSes 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: quanah(a)openldap.org Target Milestone: --- Initially reported to me directly as an issue with NetBSD 9.1, I was able to reproduce this with FreeBSD 13.1 as well. Investigation ongoing. Running test050 in a loop eventually results in a deadlock in one of the 4 slapd provider processes. -- You are receiving this mail because: You are on the CC list for the issue.

1 15

[Issue 9898] New: slapd-addel.c contains invalid struct initialization which does not compile on HP-UX aCC
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9898 Issue ID: 9898 Summary: slapd-addel.c contains invalid struct initialization which does not compile on HP-UX aCC Product: OpenLDAP Version: 2.6.3 Hardware: All OS: Other Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: michael.osipov(a)siemens.com Target Milestone: --- My compiler (cc: HP C/aC++ B3910B A.06.29 [Oct 18 2016]) gives me: /opt/aCC/bin/aCC -Ae -g -I../../include -I../../include -I/opt/ports/include -I/opt/ports/include -c -o slapd-addel.o slapd-addel.c "slapd-addel.c", line 68: error #2029: expected an expression LDIFRecord record = {}; ^ "slapd-addel.c", line 70: error #2029: expected an expression struct berval bv = {}; ^ This is invalid C code, it can be easily solved by using "{0}" and the code does compile. -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 9892] New: LDAP_TXN_SPECIFY assumes cleanup responsibility for writes but never performs it
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9892 Issue ID: 9892 Summary: LDAP_TXN_SPECIFY assumes cleanup responsibility for writes but never performs it 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 TXN extop is accepted and the client sends some write ops, the cleanup path is skipped within do_modify/do_add/... however the data is never actually freed when the transaction is being settled (regardless of whether it was committed successfully or aborted). Confirmed to happen with do_modify by tests/scripts/lloadd/test007-coherence, for others it's my assumption based on reading the code. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9880] New: reqStart filter with trailing zeros is truncated, which breaks certain searches
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9880 Issue ID: 9880 Summary: reqStart filter with trailing zeros is truncated, which breaks certain searches Product: OpenLDAP Version: 2.5.12 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: subbarao(a)computer.org Target Milestone: --- Note: ITS#9358 seems to address this very issue, but it doesn't seem to help this particular case. Certain range searches with reqStart on the changelog don't work as expected. For example: (!(reqStart<=20220707123456.000000Z)) The idea here is to grab all entries strictly greater than the timestamp. But slapd truncates zeros in this filter, rewriting it to: (!(reqStart<=20220707123456Z)) As a result, the reqStart=20220707123456.000000Z entry is the first match since it is greater than 20220707123456Z, which is not the desired behavior. I was able to reproduce this issue on 2.5.12 as follows: 1) Start the test043-delta-syncrepl test, let it run almost to the end so that it makes many changes, and then hit ^Z to suspend the script. I waited until one of the last occurrences of "Waiting 7 seconds for syncrepl to receive changes". 2) pkill -CONT -f slapd to restart slapd (but not the test script) 3) ldapsearch -x -h localhost:9011 -b cn=log objectclass=top | grep '^dn:.*.000000Z' Look for a change with all trailing zeros. It's not as rare as one might think, I saw at least one trailing-zeros change in two consecutive runs of the test script. I suppose you could also just create an entry with all trailing zeros in the accesslog :-) 4) Run a range search to only return changes after that change (I used -z 1 and -s one so that it would only give me one result): ldapsearch -x -z 1 -h localhost:9011 -b cn=log -s one '(!(reqStart<=20220708012121.000000Z))' If you see the same entry, then the problem is present. 5) Even if you can't have an accesslog entry with all trailing zeros, you can still do the above search verbatim and look at the slapd log file testrun/slapd.1.log: 62c7873f.145b4396 0x7fabf14c9700 conn=1011 op=1 SRCH base="cn=log" scope=1 deref =0 filter="(!(reqStart<=20220708012121Z))" The filter being rewritten in the server log seems to indicate that trailing zeros are being truncated somewhere. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs