https://bugs.openldap.org/show_bug.cgi?id=6825
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.
https://bugs.openldap.org/show_bug.cgi?id=8890
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|TEST |FIXED
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10458
Issue ID: 10458
Summary: improve handling of large entry modifications
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: ---
If modifying a huge entry (e.g. a super-large group with countless members), we
(back-mdb) spends about 50% of time on memmove() in attr_dup2 just copying the
data around. We don't need this, this e_attrs doesn't outlive the mdb_modify
that transitively calls it nor do we write into the data themselves.
We should be able to tell attrs_dup that it can reuse parts of the original
attributes and set `SLAP_ATTR_DONT_FREE_DATA` on the resulting attributes if
the caller claims it will take care of the lifetimes accordingly, including any
new values it puts in.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=6462
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|TEST |FIXED
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.
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.
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.
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.
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.
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.
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.