openldap-bugs March 2025

openldap-bugs@openldap.org

1 participants
44 discussions

[Issue 10026] New: Refresh handling can skip entries (si_dirty not managed properly)
by openldap-its＠openldap.org 25 Mar '25

25 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=10026 Issue ID: 10026 Summary: Refresh handling can skip entries (si_dirty not managed properly) Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Take MPR plain syncrepl with 3+ providers. When a provider's own syncrepl session transitions to persist and a it starts a new parallel session towards another host, that session always has to start as a refresh. If that refresh serves entries to us, our handling of si_dirty is not consistent: - if the existing persist session serves some of these entries to us, we can "forget" to pass the others to a newly connected consumer - same if the refresh is abandoned and we start refreshing from a different provider that might be behind what we were being served (again our consumers could suffer) - if we restart, si_dirty is forgotten and our consumers suffer even worse We might need to be told (at the beginning of the refresh?) what the end state we're going for is, so we can keep si_dirty on until then. And somehow persist that knowledge in the DB... -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 10205] New: SSL handshake blocks forever in async mode if server unaccessible
by openldap-its＠openldap.org 25 Mar '25

25 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=10205 Issue ID: 10205 Summary: SSL handshake blocks forever in async mode if server unaccessible Product: OpenLDAP Version: 2.5.17 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: regtube(a)hotmail.com Target Milestone: --- When ldaps:// scheme is used to connect to currently unaccessible server with LDAP_OPT_CONNECT_ASYNC and LDAP_OPT_NETWORK_TIMEOUT options set, it blocks forever on SSL_connect. Here is a trace: ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP winserv.test.net:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.56.2:636 ldap_pvt_connect: fd: 3 tm: 30 async: -1 ldap_ndelay_on: 3 attempting to connect: connect errno: 115 ldap_int_poll: fd: 3 tm: 0 ldap_err2string [2024-04-25 15:41:27.112] [error] [:1] bind(): Connecting (X) [2024-04-25 15:41:27.112] [error] [:1] err: -18 ldap_sasl_bind ldap_send_initial_request ldap_int_poll: fd: 3 tm: 0 ldap_is_sock_ready: 3 ldap_ndelay_off: 3 TLS trace: SSL_connect:before SSL initialization TLS trace: SSL_connect:SSLv3/TLS write client hello Looks like it happens because non-blocking mode is cleared from the socket (ldap_ndelay_off) after the first poll for write, and non-blocking mode is never restored before attempt to do tls connect, because of the check that assumes that non-blocking mode has already been set for async mode: if ( !async ) { /* if async, this has already been set */ ber_sockbuf_ctrl( sb, LBER_SB_OPT_SET_NONBLOCK, (void*)1 ); } while in fact it was cleared. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10162] New: Fix for binary attributes data corruption in back-sql
by openldap-its＠openldap.org 25 Mar '25

25 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=10162 Issue ID: 10162 Summary: Fix for binary attributes data corruption in back-sql Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: dex.tracers(a)gmail.com Target Milestone: --- Created attachment 1006 --> https://bugs.openldap.org/attachment.cgi?id=1006&action=edit Fix for binary attributes corruption on backed-sql I've configured slapd to use back-sql (mariadb through odbc) and observed issues with the BINARY data retrievals from the database. The length of the attributes was properly reported, but the correct data inside was always 16384 bytes and after that point - some junk (usually filled-up with AAAAAAAA and some other attributes data from memory). During the debugging - I've noticed that: - The MAX_ATTR_LEN (16384 bytes) is used to set the length of the data for BINARY columns when SQLBindCol is done inside of the "backsql_BindRowAsStrings_x" function - After SQLFetch is done - data in row->cols[i] is fetched up to the specified MAX_ATTR_LEN - After SQLFetch is done - the correct data size (greater than MAX_ATTR_LEN) is represented inside of the row->value_len I'm assuming that slapd allocates the pointer in memory (row->cols[i]), fills it with the specified amount of data (MAX_ATTR_LEN), but when forming the actual attribute data - uses the length from row->value_len and so everything from 16384 bytes position till row->value_len is just a junk from the memory (uninitialized, leftovers, data from other variables). After an investigation, I've find-out that: - for BINARY or variable length fields - SQLGetData should be used - SQLGetData supports chunked mode (if length is unknown) or full-read mode if the length is known - it could be used in pair with SQLBindCol after SQLFetch (!) Since we have the correct data length inside of row->value_len, I've just added the code to the backsql_get_attr_vals() function to overwrite the corrupted data with the correct data by issuing SQLGetData request. And it worked - binary data was properly retrieved and reported over LDAP! My current concerns / help needed - I'm not very familiar with the memory allocation/deallocation mechanisms, so I'm afraid that mentioned change can lead to memory corruption (so far not observed). Please review attached patch (testing was done on OPENLDAP_REL_ENG_2_5_13, and applied on the master branch for easier review/application). -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 7901] slapschema reports error but returns 0
by openldap-its＠openldap.org 25 Mar '25

25 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=7901 --- Comment #3 from requate(a)univention.de <requate(a)univention.de> --- Created attachment 1060 --> https://bugs.openldap.org/attachment.cgi?id=1060&action=edit slapschema-continuemode-and-preserve-rc.patch This extended version of the patch additionally preserves a non-zero return code even in combination with the option "-c". -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7901] slapschema reports error but returns 0
by openldap-its＠openldap.org 25 Mar '25

25 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=7901 --- Comment #2 from requate(a)univention.de <requate(a)univention.de> --- Created attachment 1059 --> https://bugs.openldap.org/attachment.cgi?id=1059&action=edit slapschema-continuemode.patch If the last object checked by entry_schema_check() has a problem, then slapschema returns the error code of that problem. But if there is a good object check after that, then it returns 0. That is not ideal. The tool offers the option "-c" to activate a "continuemode". The man page states "Enable continue (ignore errors) mode" and it is a bit surprising that the default behavior is different for the the return code of the main check. Also, while the message `# (65) Object class violation: unrecognized objectClass 'foo'` is output to stdout, the messages `67e293be UNKNOWN attributeDescription "BAR" inserted.` are actually output to stderr. They seem related, maybe it would be more consistent to output them to the same channel. The attached patch just proposes to exit the check loop in case entry_schema_check() fails and the option "-c" was not given. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10316] New: build/lib/mdb.c:5882: Assertion 'IS_BRANCH(mc->mc_pg[mc->mc_top])' failed in mdb_cursor_sibling()
by openldap-its＠openldap.org 11 Mar '25

11 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=10316 Issue ID: 10316 Summary: build/lib/mdb.c:5882: Assertion 'IS_BRANCH(mc->mc_pg[mc->mc_top])' failed in mdb_cursor_sibling() Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: stefan(a)konink.de Target Milestone: --- I am developing ETL software in Python and I am using lmdb as backend. For this I am using https://github.com/jnwatson/py-lmdb In this big process I am resizing the map_size dynamically. I would say it is certainly possible that I am reading at the same time. I end up in the following error: build/lib/mdb.c:5882: Assertion 'IS_BRANCH(mc->mc_pg[mc->mc_top])' failed in mdb_cursor_sibling() I ran my application again with a predetermined map size, and it did not assert. Since it is a single shot, I don't know if I can be certain that it therefore does not happen. When searching for it I found the following issue from 2017, suggesting it can be reproduced when running the performance test. https://github.com/bnclabs/dbperf/issues/1 -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10315] Re-Usage of Message IDs of async search blocks all available connections
by openldap-its＠openldap.org 11 Mar '25

11 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=10315 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 10315] Re-Usage of Message IDs of async search blocks all available connections
by openldap-its＠openldap.org 11 Mar '25

11 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=10315 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #7 from Quanah Gibson-Mount <quanah(a)openldap.org> --- No OpenLDAP issue seen. Use proper file limit settings. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10315] Re-Usage of Message IDs of async search blocks all available connections
by openldap-its＠openldap.org 11 Mar '25

11 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=10315 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Group|OpenLDAP-devs | Keywords|needs_review | -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10318] New: Potential null-pointer-dereference in servers/slapd/connection.c
by openldap-its＠openldap.org 11 Mar '25

11 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=10318 Issue ID: 10318 Summary: Potential null-pointer-dereference in servers/slapd/connection.c Product: OpenLDAP Version: 2.5.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: 1367173408(a)qq.com Target Milestone: --- Created attachment 1056 --> https://bugs.openldap.org/attachment.cgi?id=1056&action=edit execution trace Hi, I have found a potential null pointer dereference bug in the project and would like to report it to the maintainers. At line 267 and line 284 in file `servers/slapd/connection.c`, the function `connection_get` may return NULL. Then, at line 1239 in the same file, the pointer `c` receives the return value, which may be NULL. But `c` is dereferenced at following lines without checking, which may lead to a null-pointer-dereference bug. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2025