openldap-bugs

openldap-bugs@openldap.org

1 participants
21518 discussions

[Issue 9796] New: Deprecate GnuTLS support
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=9796 Issue ID: 9796 Summary: Deprecate GnuTLS support Product: OpenLDAP Version: 2.6.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Support for GnuTLS was added specifically for the Debian (and thus Ubuntu) due to the license objections at the time that the Debian project had for the OpenSSL license. Since that time, Debian has reclassified OpenSSL as a core library and the OpenSSL project has resolved the original complaint by licensing OpenSSL 3 and later under the Apache License v2. Thus there is no longer a reason to maintain support for GnuTLS and given the long standing concerns over the security and quality of the GnuTLS bridge in addition to the extra cost of maintaining that code, it should be marked as deprecated and removed in a future release. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 10338] New: constraint overlay rejects empty modifications
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10338 Issue ID: 10338 Summary: constraint overlay rejects empty modifications 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: --- If configured even with no rules, a modification with a NULL op->orm_modlist is rejected, despite not being able to break any constraints, e.g.: dn: cn=example changetype: modify # no modifications attached This should at least be configurable. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10488] New: Multiple out-of-bounds reads in servers/slapd/result.c v2ref() function
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10488 Issue ID: 10488 Summary: Multiple out-of-bounds reads in servers/slapd/result.c v2ref() function Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: wangxiaomeng(a)kylinos.cn Target Milestone: --- Created attachment 1142 --> https://bugs.openldap.org/attachment.cgi?id=1142&action=edit Fix two out-of-bounds reads in servers/slapd/result.c v2ref() function The v2ref() function in servers/slapd/result.c is responsible for converting LDAPv3 referrals to an LDAPv2-compatible string format. Two separate out-of-bounds read vulnerabilities exist in this function, both caused by insufficient checks for zero-length data before accessing the last character of the data buffer. Vulnerability 1: Out-of-bounds read in text buffer handling Location: servers/slapd/result.c, line 94 (within the v2ref() function): Vulnerable Code: if ( text != NULL ) { len = strlen( text ); if (text[len-1] != '\n') { i = 1; } } When the 'text' parameter is non-NULL but points to an empty string (""), strlen(text) returns 0. Accessing text[len-1] (i.e., text[-1]) results in an out-of-bounds read of one byte before the start of the 'text' buffer. Vulnerability 2: Out-of-bounds read in BerValue referral handling Location: servers/slapd/result.c, line 115 (within the v2ref() function) Vulnerable Code: len += ref[i].bv_len; if (ref[i].bv_val[ref[i].bv_len-1] != '/') { ++len; } When ref[i].bv_val is non-NULL but ref[i].bv_len is 0 (a valid state per LDAP BerValue semantics, representing an empty string), accessing ref[i].bv_val[ref[i].bv_len-1] (i.e., ref[i].bv_val[-1]) results in an out-of-bounds read of one byte before the start of the ref[i].bv_val buffer. Fix Add checks for zero-length data before accessing the last character of the respective buffers. The fix addresses both vulnerabilities with minimal, targeted changes that preserve the original functionality. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 10497] New: o_ctrlflags usage confused
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10497 Issue ID: 10497 Summary: o_ctrlflags usage confused 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: --- There is widespread confusion about what is stored in o_ctrlflags (and retrieved with get_<control> macros.) Some code is spot on e.g., get_pagedresults() and checks for SLAP_CONTROL_NON/CRITICAL/IGNORED as it should, most of them expect 0/1 (assert, manageDSAiT, ...) We could correct all the get_* tests to check for > IGNORED or just add a has_ variant if we want to keep the code simple for those that don't need to bother. And we want to fix autogroup to set o.o_permissive_modify correctly. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10456] New: Record time it took to run purge task
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10456 Issue ID: 10456 Summary: Record time it took to run purge task 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: --- accesslog could report a summary at the end of the purge saying how long it took and how many entries were (or would have been if shutting down) removed in that run. Thinking SYNC level as that's where most accesslog's messages go already. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9493] New: slapo-accesslog handling of deletion of multi-valued configuration attributes removes wrong value from list
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=9493 Issue ID: 9493 Summary: slapo-accesslog handling of deletion of multi-valued configuration attributes removes wrong value from list Product: OpenLDAP Version: 2.4.57 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: svella(a)technologist.com Target Milestone: --- I observed this in the debugger while working on a small feature addition to slapo-accesslog. log_cf_gen(), when handling the initial configuration of oldAccessLogOldAttr (accesslog.c:989), linked list li_oldattrs is being built by inserting each value in order at the head of the list, resulting in the list being in reverse order. But when handling LDAP_MOD_DELETE of same attribute (accesslog.c:989), it is using the index of the removed value (valx) to find and removed the entry in the linked list, but it's counting from the head of li_oldattrs and not the tail, resulting in the wrong item being removed from the list unless counting from the head or the tail happens find the same item. (Line numbers refer to commit 6c469f07935e351e349bf38fc223dab704c51a76) Handling of oldAccessLogBase appears to have the same problem, and a cursory glance through the source of other overlays reveals a similar pattern, and I'm guessing the same problem. -- You are receiving this mail because: You are on the CC list for the issue.

1 22

[Issue 7226] olcAuditlogFile should be single valued, but accepts multiple values (additional values ignored)
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

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

1 0

[Issue 9556] New: slapd-config should return invalidAttributeSyntax if parsing schema description fails
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=9556 Issue ID: 9556 Summary: slapd-config should return invalidAttributeSyntax if parsing schema description fails Product: OpenLDAP Version: 2.5.4 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- I'm currently testing error handling and interacting with LDAP clients (e.g. my web2ldap). Sending an invalid attribute type description results in an error (as expected) returned by slapd-config: RESULT tag=103 err=80 qtime=0.000032 etime=0.001271 text=olcAttributeTypes: Unexpected token before SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) But result code other(80) seems not very useful. It's too unspecific to decide on specific error handling. It would be much more useful if slapd-config returns invalidAttributeSyntax(21) in this case. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9959] New: Expose the lloadd connection endpoints in cn=monitor for identification
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=9959 Issue ID: 9959 Summary: Expose the lloadd connection endpoints in cn=monitor for identification 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: --- ITS#9600 introduces a way to operate on lloadd connections, however it is impossible to identify which socket this actually corresponds to. While we're at it, might also expose the current bound identity there. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10266] New: Adopt broader RFC4511 NoD interpretation on lloadd's client side
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10266 Issue ID: 10266 Summary: Adopt broader RFC4511 NoD interpretation on lloadd's client side 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: --- Server side, lloadd has long implemented a broad interpretation of NoD unsolicited response handling: when the message is issued, no new requests are accepted on the session however the client and server are both free to keep the session open if there are any operations that have not resolved yet. The server is still expected to close the connection as soon as no operations are still pending. This seems to interoperate with known clients. Those that want to will close the session immediately, unaware of this possibility, those that also want to interpret RFC 4511 this way can choose to wait for existing operations to resolve. This ticket is to track the lloadd's implementation of the client side of this - when receiving a NoD message, we don't close the connection immediately+unconditionally either but are willing to wait. Related functionality: - if connection was a bind connection processing a multi-stage SASL bind, the bind should fail if/when the client attempts to progress it - clients assigned to this connection through coherence at least 'connection' are also marked closing -- You are receiving this mail because: You are on the CC list for the issue.

1 5

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs