https://bugs.openldap.org/show_bug.cgi?id=9997
Issue ID: 9997
Summary: Potential memory leak in servers/slapd/syncrepl.c
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: 1061499390(a)qq.com
Target Milestone: ---
Version: Github:master
Potential memory leak in syncrepl.c line 605.Calling ldap_search_ext_s()
without calling ldap_msgfree() to free the memory will cause a memory leak.
Doc says "Note that res parameter of ldap_search_ext_s() and
ldap_search_s() should be freed with ldap_msgfree() regardless of return value
of these functions." in
https://www.openldap.org/software/man.cgi?query=ldap_search_ext_s&apropos=0…
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9990
Issue ID: 9990
Summary: Part of the ITS#8698 fix breaks exop overlays that set
a callback
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: subbarao(a)computer.org
Target Milestone: ---
We have a password exop overlay that sets up a callback, which has stopped
working when upgrading to 2.5.13. and I tracked it down to a change to
servers/slapd/passwd.c implemented as part of the fix for ITS#8698:
https://git.openldap.org/openldap/openldap/-/merge_requests/304/diffs?commi…
It appears that the intent of this change was to loop through the o_callback
list and only remove the cb callback created in this section of the code. But
that isn't necessary because the cb callback never gets added to the original
list. With this change, line 295 clobbers the original o_callback list which
never gets restored -- that's why our exop overlay stopped working.
Fortunately, the fix is very simple -- just revert this part of the change. The
original code already saved/restored the o_callback list properly.
When I reverted this part of the change, our exop overlay resumed working, and
the rest of the ITS#8698 functionality (messages from the pwdCheckModule module
being returned to the user) also worked as expected.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10003
Issue ID: 10003
Summary: Potential Use After Free in libraries/libldap/open.c
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: 1061499390(a)qq.com
Target Milestone: ---
Version: Github:master
Potential Use After Free in open.c line 590.
Doc says "Once it(ldap_unbind) is called, the connection to the LDAP server
is closed, and the ld structure is invalid."
in
https://www.openldap.org/software/man.cgi?query=ldap_unbind_ext&apropos=0&s…
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9998
Issue ID: 9998
Summary: Potential memory leak in tests/progs/slapd-mtread.c
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: test suite
Assignee: bugs(a)openldap.org
Reporter: 1061499390(a)qq.com
Target Milestone: ---
Version: Github:master
Potential memory leak in slapd-mtread.c line 520.Calling ldap_search_ext_s()
without calling ldap_msgfree() to free the memory will cause a memory leak.
Doc says "Note that res parameter of ldap_search_ext_s() and
ldap_search_s() should be freed with ldap_msgfree() regardless of return value
of these functions." in
https://www.openldap.org/software/man.cgi?query=ldap_search_ext_s&apropos=0…
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10015
Issue ID: 10015
Summary: Config File KEEPALIVE_IDLE KEEPALIVE_PROBES
KEEPALIVE_INTERVAL parser does random memory write
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: sean(a)teletech.com.au
Target Milestone: ---
In openldap/libraries/libldap/init.c: [master branch]
The Config File integers
KEEPALIVE_IDLE
KEEPALIVE_PROBES
KEEPALIVE_INTERVAL
Should be struct ol_attribute.type ATTR_OPT_INT rather than ATTR_INT.
ATTR_INT interprets struct ol_attribute.offset as a pointer to integer.
ATTR_OPT_INT interprets struct ol_attribute.offset as an option number to be
passed to ldap_set_option()
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10016
Issue ID: 10016
Summary: syncprov may abandon a psearch improperly
Product: OpenLDAP
Version: 2.5.13
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
When processing an Abandon, it may remove the detached search op from the
connection while the qtask is actively sending search responses on the
connection. If the Abandon is due to an Unbind or connection loss, the
connection structure may get reused by a new conn while the qtask is still
running.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9953
Issue ID: 9953
Summary: Push replication issue for the pwdHistory attribute
Product: OpenLDAP
Version: 2.4.57
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: dh(a)dotlan.net
Target Milestone: ---
Hello,
I'm using a master ldap instance with a push replication instance to external
slaves using the ldap backend on Debian 11 (2.4.57) and I came across some
replication issues that forces me to drop the slave dbs and do a manually
fullsync everything this error occurs.
The problem
===========
I know that replication and maintaining a password policy is a complicated
task, especially since the ppolicy overlay must be loaded and active in every
instance (master, push instance, slave). This problem leads to interesting
challanges.
First, I encountered a problem where pwdChangedTime would be duplicate because
the ppolicy overlay of the push instance and the back_ldap/slave instance would
like to set it (which leads to a duplicate attribute error). To fix problem I
backported the patch [1] to my local version of the slapd packages. After this
problem was fixed, I've encountered the next problematic attribute:
"pwdHistory". I've play around with some syncrepl settings, but in the end, it
seems to be a similar issue. It looks likes the pwdHistory attribute is not yet
present on the slave and both instances (push and slave) try to add the
pwdHistory Attributes which leads to a problem where both entries collied
(pwdHistory: value #0 already exists). For whatever reason pwdHistory doesn't
show up as modified field on the slave in the MOD request. But anyways.
Something seems to be wrong, and it could a similar replication issue compared
with pwdChangedTime
I've lookup into the change history of the ppolicy.c file in the 2.5 and 2.6
branch but couldn't find a newer commit that would address this issue.
Does anyone has encountered a similar issue? I've not played around with the
2.5 or 2.6 version, but looking at the code, I've either not seen a fix or the
problem might still exist, hopefully I am wrong. Any suggestions?
--
best regards
Daniel Hoffend
[1]
https://github.com/openldap/openldap/commit/7a34f46d1cabe8e80937d5167b62152…
Setup
=====
Host Master
- Debian 11 slapd 2.4.57+dfsg-3
- slapd master instance with cn=config
- push replikation instance with simple config (syncrepl from localhost, write
to backend ldap)
Host Slave
- Debian 11 slapd 2.4.57+dfsg-3
- Readonly slave
On all 3 instances ppolicy is enabled otherwise the operational attributes
would be not known/available and sync of locked accounts or per account
selected password policy assignment wouldn't work.
PUSH Replication Instance
=========================
database ldap
[...]
overlay ppolicy
ppolicy_default "cn=default,ou=policies,dc=example,dc=org"
syncrepl rid=__RID__
provider=ldap://localhost:389/
binddn="cn=replication,ou=system,dc=example,dc=org"
bindmethod=simple
credentials="secret"
searchbase="dc=example,dc=org"
type=refreshAndPersist
schemachecking=off
retry="5 12 60 +"
attrs="*,memberOf,pwdPolicySubentry,pwdChangedTime,pwdAccountLockedTime,pwdHistory,creatorsName,createTimestamp,modifiersName,modifyTimestamp"
---
Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_message_to_entry: rid=016
DN: uid=user1,ou=accounts,dc=example,dc=org, UUID:
db720f56-df0d-103c-8635-9543ccd6e97d
Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_entry: rid=016
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid a0a89700
Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_entry: rid=016 be_search
(0)
Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_entry: rid=016
uid=user1,ou=accounts,dc=example,dc=org
Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_null_callback : error code
0x14
Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_entry: rid=016 be_modify
uid=user1,ou=accounts,dc=example,dc=org (20)
Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_entry: rid=016 be_modify
failed (20)
Nov 3 00:00:45 ldapmaster slapd[2308611]: do_syncrepl: rid=016 rc 20 retrying
SLAVE LDAP Server
=================
database mdb
[...]
overlay ppolicy
ppolicy_default "cn=default,ou=policies,dc=example,dc=org"
---
Nov 3 00:00:45 ldapslave slapd[2221506]: conn=176499 op=59513 SRCH
base="uid=user1,ou=accounts,dc=example,dc=org" scope=0 deref=0
filter="(objectClass=*)"
Nov 3 00:00:45 ldapslave slapd[2221506]: conn=176499 op=59513 SEARCH RESULT
tag=101 err=0 nentries=1 text=
Nov 3 00:00:45 ldapslave slapd[2221506]: conn=176500 op=59513 MOD
dn="uid=user1,ou=accounts,dc=example,dc=org"
Nov 3 00:00:45 ldapslave slapd[2221506]: conn=176500 op=59513 MOD
attr=structuralObjectClass creatorsName createTimestamp userPassword
pwdChangedTime memberOf entryCSN modifiersName modifyTimestamp
Nov 3 00:00:45 ldapslave slapd[2221506]: conn=176500 op=59513 RESULT tag=103
err=20 text=modify/add: pwdHistory: value #0 already exists
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10004
Issue ID: 10004
Summary: Potential memory leak in
libraries/librewrite/ldapmap.c
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: 1061499390(a)qq.com
Target Milestone: ---
Version: Github:master
Potential memory leak in ldapmap.c line 310, 321.Calling ldap_initialize()
without calling ldap_unbind_ext() to free the memory will cause a memory leak.
There is no ldap_unbind_ext before calling ldap_initialize in line 376, and the
ld will be allocated again.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9999
Issue ID: 9999
Summary: Potential memory leak in tests/progs/slapd-search.c
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: test suite
Assignee: bugs(a)openldap.org
Reporter: 1061499390(a)qq.com
Target Milestone: ---
Version: Github:master
Potential memory leak in slapd-search.c line 207.Calling ldap_search_ext_s()
without calling ldap_msgfree() to free the memory will cause a memory leak.
Doc says "Note that res parameter of ldap_search_ext_s() and
ldap_search_s() should be freed with ldap_msgfree() regardless of return value
of these functions." in
https://www.openldap.org/software/man.cgi?query=ldap_search_ext_s&apropos=0…
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9996
Issue ID: 9996
Summary: Potential memory leak in
libraries/librewrite/ldapmap.c
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: 1061499390(a)qq.com
Target Milestone: ---
Version: Github:master
Potential memory leak in ldapmap.c line 359.Calling ldap_search_ext_s() without
calling ldap_msgfree() to free the memory will cause a memory leak.
Doc says "Note that res parameter of ldap_search_ext_s() and
ldap_search_s() should be freed with ldap_msgfree() regardless of return value
of these functions." in
https://www.openldap.org/software/man.cgi?query=ldap_search_ext_s&apropos=0…
--
You are receiving this mail because:
You are on the CC list for the issue.