openldap-bugs

openldap-bugs@openldap.org

1 participants
20993 discussions

[Issue 8988] Undefined Behavior in slapadd
by openldap-its＠openldap.org 02 Jan '25

02 Jan '25

https://bugs.openldap.org/show_bug.cgi?id=8988 --- Comment #27 from jhaberman(a)gmail.com --- Unfortunately I can still reproduce this with LMDB 0.9.33. Repro: #include <stdlib.h> #include <string.h> #include <stdio.h> #include "lmdb.h" #define VAL(str) {strlen(str), str} #define CHK(st) if (st != 0) { fprintf(stderr, "fail at %d\n", __LINE__); abort(); } int main() { MDB_env* lmdb; int status; status= mdb_env_create(&lmdb); CHK(status); status = mdb_env_open(lmdb, "/tmp/lmdb_repro", 0, 0644); CHK(status); MDB_txn* txn; status = mdb_txn_begin(lmdb, NULL, 0, &txn); CHK(status); MDB_dbi dbi; status = mdb_dbi_open(txn, NULL, MDB_CREATE | MDB_DUPSORT, &dbi); CHK(status); MDB_val k = VAL("key"); MDB_val v1 = VAL("val1"); status = mdb_put(txn, dbi, &k, &v1, MDB_NODUPDATA); CHK(status); MDB_val v2 = VAL("val2"); status = mdb_put(txn, dbi, &k, &v2, MDB_NODUPDATA); CHK(status); return 0; } $ clang -fsanitize=undefined -o repro repro.c mdb.c midl.c $ mkdir /tmp/lmdb_repro $ ./repro Output: --- mdb.c:7654:26: runtime error: member access within misaligned address 0x561c906b85d3 for type 'MDB_page2' (aka 'struct MDB_page2'), which requires 2 byte alignment 0x561c906b85d3: note: pointer points here 00 6b 65 79 02 00 00 00 00 00 00 00 00 00 52 00 10 00 2c 00 76 61 6c 31 00 00 00 00 00 00 00 00 ^ SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior mdb.c:7654:26 in mdb.c:7654:26: runtime error: load of misaligned address 0x561c906b85df for type 'indx_t' (aka 'unsigned short'), which requires 2 byte alignment 0x561c906b85df: note: pointer points here 00 00 52 00 10 00 2c 00 76 61 6c 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior mdb.c:7654:26 in mdb.c:7655:3: runtime error: member access within misaligned address 0x561c906b85d3 for type 'MDB_page' (aka 'struct MDB_page'), which requires 8 byte alignment 0x561c906b85d3: note: pointer points here 00 6b 65 79 02 00 00 00 00 00 00 00 00 00 52 00 10 00 2c 00 76 61 6c 31 00 00 00 00 00 00 00 00 [...] --- It appears that some instances of MDB_page2 are not 2-byte aligned. Is this expected? -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8988] Undefined Behavior in slapadd
by openldap-its＠openldap.org 02 Jan '25

02 Jan '25

https://bugs.openldap.org/show_bug.cgi?id=8988 --- Comment #26 from jhaberman(a)gmail.com --- I see now that https://github.com/LMDB/lmdb/commit/3947014aed7ffe39a79991fa7fb5b234da47ad1a may have fixed this issue. I was using a version older than this commit. I will try updating and see if that fixes the problem. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8988] Undefined Behavior in slapadd
by openldap-its＠openldap.org 01 Jan '25

01 Jan '25

https://bugs.openldap.org/show_bug.cgi?id=8988 --- Comment #25 from jhaberman(a)gmail.com --- I ran into this UBSAN error today: > third_party/liblmdb/mdb.c:7559:26: runtime error: member access within misaligned address 0x32577fcf7fd3 for type 'MDB_page' (aka 'struct MDB_page'), which requires 8 byte alignment 0x32577fcf7fd3: note: pointer points here 00 66 6f 6f 02 00 00 00 00 00 00 00 00 00 52 00 10 00 2c 00 00 00 00 00 00 00 00 00 62 61 72 00 This corresponds to this line: https://github.com/LMDB/lmdb/blob/da9aeda08c3ff710a0d47d61a079f5a905b0a10a/… > mx->mx_db.md_entries = NUMKEYS(fp); From the bug log I see that there is disagreement over the interpretation of UB. Language lawyering aside, this issue makes it difficult to use LMDB in environments where UBSAN is in use. I also worry about the potential for miscompiles if the compiler is using its own interpretation of UB, and optimizing based on the assumption that UB cannot happen. Is there any way to make LMDB pack its structures less aggressively, so that it will satisfy UBSAN's alignment expectations? Alternatively, there are ways to perform the accesses that make UBSAN happy, but they make the code uglier: https://godbolt.org/z/8EP6cW77s > The code in question is accessing an unsigned short on a 2 byte boundary. I.e., its alignment is correct. UBsan is incorrect here. I cannot speak for the UBSAN authors, but I believe the issue is that, since p->x is equivalent to (*p).x, the dereference of p must be valid, even if x's alignment requirements are looser. To avoid this, you could write *(uint16_t*)((char*)p + offsetof(S, x)), since this avoids actually dereferencing p. But this is obviously much less readable. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10291] New: OpenLDAP matches localhost against local hostname incorrectly
by openldap-its＠openldap.org 18 Dec '24

18 Dec '24

https://bugs.openldap.org/show_bug.cgi?id=10291 Issue ID: 10291 Summary: OpenLDAP matches localhost against local hostname incorrectly Product: OpenLDAP Version: 2.6.2 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: cmousefi(a)gmail.com Target Milestone: --- When connecting to a localhost LDAP server using TLS, I get this in debug log: # ldapsearch -ZZ -H ldap://localhost/ -d9 <skip...> TLS trace: SSL_connect:before SSL initialization TLS trace: SSL_connect:SSLv3/TLS write client hello TLS trace: SSL_connect:SSLv3/TLS write client hello TLS trace: SSL_connect:SSLv3/TLS read server hello TLS trace: SSL_connect:TLSv1.3 read encrypted extensions TLS certificate verification: depth: 1, err: 0, subject: /CN=Test LDAP CA Root, issuer: /CN=Test LDAP CA Root TLS certificate verification: depth: 0, err: 0, subject: /CN=localhost, issuer: /CN=Test LDAP CA Root TLS trace: SSL_connect:SSLv3/TLS read server certificate TLS trace: SSL_connect:TLSv1.3 read server certificate verify TLS trace: SSL_connect:SSLv3/TLS read finished TLS trace: SSL_connect:SSLv3/TLS write change cipher spec TLS trace: SSL_connect:SSLv3/TLS write finished TLS: hostname (1384a4485398) does not match common name in certificate (localhost). TLS: can't connect: TLS: hostname does not match name in peer certificate. ldap_err2string ldap_start_tls: Connect error (-11) additional info: TLS: hostname does not match name in peer certificate Expected behaviour: When connecting to localhost, I would expect the certificate issued to localhost to work. Actual behaviour: Certificate is issued to localhost but ldapsearch matches against local hostname. Here is the server certificate textual presentation subject=CN=localhost Certificate: Data: Version: 3 (0x2) Serial Number: 41:68:1b:be:cb:46:95:45:e7:72:03:8b:6c:b4:75:55:ca:5c:cb:c9 Signature Algorithm: ecdsa-with-SHA256 Issuer: CN=Test LDAP CA Root Validity Not Before: Dec 3 19:04:58 2024 GMT Not After : Sep 2 19:04:58 2034 GMT Subject: CN=localhost Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:f5:f1:f4:7d:56:85:87:b2:98:c9:b2:a2:83:ef: 52:71:01:1e:81:64:9f:64:ec:99:5a:e4:38:63:13: 69:de:09:00:1e:a1:e1:83:4a:c6:58:0d:c0:bb:4f: 36:7f:5a:f7:8f:74:b4:e2:96:06:09:9b:2c:0d:fb: 8c:6d:57:44:2e ASN1 OID: prime256v1 NIST CURVE: P-256 X509v3 extensions: X509v3 Subject Key Identifier: 5A:54:AF:41:E8:A0:EC:3D:28:3D:D6:0D:91:20:97:73:FA:40:AE:9C X509v3 Authority Key Identifier: FB:AF:31:4B:A2:2B:E1:DA:55:6A:3F:EE:D1:A4:74:51:C7:B9:9F:A7 X509v3 Basic Constraints: critical CA:FALSE X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 Subject Alternative Name: IP Address:127.0.0.1, IP Address:0:0:0:0:0:0:0:1, DNS:localhost, DNS:localhost.localdomain Signature Algorithm: ecdsa-with-SHA256 Signature Value: 30:46:02:21:00:d4:9a:16:ba:6e:1d:c7:df:bd:5b:3d:56:b7: 0d:ea:aa:a7:7a:7f:d0:c1:ed:77:11:48:e8:aa:b1:6a:a8:ac: 28:02:21:00:d8:41:3d:a0:52:c8:2b:cc:13:34:46:1b:34:dd: 96:87:e5:7c:71:62:50:f3:2d:b1:18:3d:ce:27:34:c9:c4:32 -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10292] New: LMDB documentation is unavailable. lmdb.tech domain has expired
by openldap-its＠openldap.org 17 Dec '24

17 Dec '24

https://bugs.openldap.org/show_bug.cgi?id=10292 Issue ID: 10292 Summary: LMDB documentation is unavailable. lmdb.tech domain has expired Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: vadim.kovalyov(a)gmail.com Target Milestone: --- LMDB documentation is unavailable. lmdb.tech domain has expired. I can't find the documentation anywhere else. If domain is gone, at least we need to update the openldap website to point to a (new) documentation site. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9886] New: At "sync" logging, nothing shows how long a write op took on consumers
by openldap-its＠openldap.org 17 Dec '24

17 Dec '24

https://bugs.openldap.org/show_bug.cgi?id=9886 Issue ID: 9886 Summary: At "sync" logging, nothing shows how long a write op took on consumers Product: OpenLDAP Version: unspecified 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: --- If sync logging is enabled on a consumer, there's no etime logged which means it is not possible to see how long a write op took on that consumer. This can be useful information to see how the node is performing, particularly if it is a read only node where there will be no general MOD timing logged. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10289] New: myldap
by openldap-its＠openldap.org 17 Dec '24

17 Dec '24

https://bugs.openldap.org/show_bug.cgi?id=10289 Issue ID: 10289 Summary: myldap Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: cmp(a)tutanota.de Target Milestone: --- -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10275] New: mdb_load could use a parameter to pass batch size
by openldap-its＠openldap.org 10 Dec '24

10 Dec '24

https://bugs.openldap.org/show_bug.cgi?id=10275 Issue ID: 10275 Summary: mdb_load could use a parameter to pass batch size Product: LMDB Version: 0.9.21 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: tools Assignee: bugs(a)openldap.org Reporter: gkwicker(a)amazon.com Target Milestone: --- Created attachment 1037 --> https://bugs.openldap.org/attachment.cgi?id=1037&action=edit Patch to mdb_load.c in version 0.9.21 mdb_load is very slow when ingesting a large db. The attached patch (0.9.21 but will apply to other versions with modification) allows the user to pass a batch size to be used instead of the default value of 100. Changing the batch size to a larger value improves ingestion speed. I, Gary Wicker, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. -- You are receiving this mail because: You are on the CC list for the issue.

1 22

[Issue 10286] New: ldap_pvt_gettime may result in "not new enough csn" problems in multi-thread case.
by openldap-its＠openldap.org 02 Dec '24

02 Dec '24

https://bugs.openldap.org/show_bug.cgi?id=10286 Issue ID: 10286 Summary: ldap_pvt_gettime may result in "not new enough csn" problems in multi-thread case. Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: 971748261(a)qq.com Target Milestone: --- Created attachment 1041 --> https://bugs.openldap.org/attachment.cgi?id=1041&action=edit the log of adding two entry which shows the time sequence. I used openldap as krb5's database, and openldap was deploymented in mirrormode. I tried to add kerberos principals via kadmin.local -q "addprinc -randkey principal. slapd log showed that the entry of kadmin/admin was added earlier than the entry of ossuser. But the csn of kadmin/admin was greater than ossuser. In this case, when the two entry began to sync to the other slapd server, ossuser was ignored because of "csn not new enough" -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 7441] cn=config filters ignore {number}
by openldap-its＠openldap.org 27 Nov '24

27 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=7441 --- Comment #3 from Ondřej Kuzník <ondra(a)mistotebe.net> --- https://git.openldap.org/openldap/openldap/-/merge_requests/662 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs