https://bugs.openldap.org/show_bug.cgi?id=9951
Issue ID: 9951
Summary: lloadd can lock up in cn=monitor modify
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: ---
lload_monitor_conn_modify's callers have borrowed the cn=monitor entry from the
cache, however it also observes memory management, so if the connection is
released and it is the last thread around, it might be responsible for freeing
it via epoch_leave(). However freeing it also requires that the connection be
removed from cn=monitor and we can deadlock there.
A fix is coming.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9913
Issue ID: 9913
Summary: Some lloadd shutdown code doesn't protect memory
correctly
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: ---
During shutdown, clients_destroy and tier_destroy are called while worker
threads might still be alive, therefore they need to participate in memory
management.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9907
Issue ID: 9907
Summary: lloadd config/shutdown leaks
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: ---
lloadd leaks some memory in cn=config and at shutdown time. Fixes coming
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9906
Issue ID: 9906
Summary: cn=monitor leaks in lloadd
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
lloadd registers various types of monitor_subsys_t but currently doesn't tear
all parts of them down correctly, leaking memory on server shutdown. Partly
down to how back-monitor shutdown works at the moment.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9045
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.
https://bugs.openldap.org/show_bug.cgi?id=9931
Issue ID: 9931
Summary: test079 broken on MacOSX
Product: OpenLDAP
Version: 2.5.12
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
Strictly-conforming getopt doesn't allow mixing of -options and plain args. All
documentation shows that LDAP attributes must be last on the ldapsearch
commandline, but the script is putting additional -options after the
olmDbConnURI attribute specification, which causes the following -options to be
ignored and the search command fails.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9991
Issue ID: 9991
Summary: slapd may close a connection twice
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: hyc(a)openldap.org
Target Milestone: ---
If slapd is sending an entry to a client, and the client is sending an Unbind
request and disconnecting at the same time, send_ldap_ber() will get an error
attempting to write on the dead socket. It will then try to call
connection_closing() to close the connection. But the frontend may also have
gotten a read error on the dead socket, and handled the close there already.
By the time send_ldap_ber() acquires the c_mutex and actually calls
connection_closing(), the conn struct may have already been assigned to a new
connection, and the connection_closing() call will erroneously close an active
session.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9955
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.
https://bugs.openldap.org/show_bug.cgi?id=9940
Issue ID: 9940
Summary: slapadd segfault with -w on a subordinate database
Product: OpenLDAP
Version: 2.5.13
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: dhawes(a)gmail.com
Target Milestone: ---
I've noticed sporadic segfaults when using slapadd with -w and an LDIF that
contains entries on a subordinate database. Removing -w prevents the segfault.
I finally had some time to look at this, and the results are odder than I
expected.
gdb bt:
=====
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000055c2096c1ffd in dnIsSuffix (dn=0x55c20b82c7b8, suffix=0x55c20b749520)
at dn.c:1192
1192 if ( d > 1 && !DN_SEPARATOR( dn->bv_val[ d - 1 ] ) ) {
(gdb) bt
#0 0x000055c2096c1ffd in dnIsSuffix (dn=0x55c20b82c7b8, suffix=0x55c20b749520)
at dn.c:1192
#1 0x000055c20974262e in glue_back_select (be=0x7fff683fc5a0,
dn=0x55c20b82c7b8) at backglue.c:77
#2 0x000055c209745473 in glue_entry_release_rw (op=0x7fff683fc840,
e=0x55c20b82c7a0, rw=0)
at backglue.c:927
#3 0x000055c20974824d in overlay_entry_release_ov (op=0x7fff683fc840,
e=0x55c20b82c7a0, rw=0,
on=0x55c20b78d870) at backover.c:439
#4 0x000055c20974841f in over_entry_release_rw (op=0x7fff683fc840,
e=0x55c20b82c7a0, rw=0)
at backover.c:483
#5 0x000055c2096b5f94 in be_entry_release_rw (op=0x7fff683fc840,
e=0x55c20b82c7a0, rw=0)
at backend.c:958
#6 0x000055c209750a3d in slap_tool_update_ctxcsn (progname=0x55c209813b08
"slapadd",
sid=18446744073709551615, bvtext=0x7fff683fca20) at slapcommon.c:1015
#7 0x000055c20974e108 in slapadd (argc=11, argv=0x7fff683fce68) at
slapadd.c:502
#8 0x000055c209672e56 in main (argc=11, argv=0x7fff683fce68) at main.c:723
(gdb) print *dn
$1 = {bv_len = 94291905136528, bv_val = 0x0}
=====
dn->bv_val is NULL in this case. This dumb patch prevents the segfault, but
does not fix the root issue:
=====
--- openldap-2.5.13/servers/slapd/dn.c 2022-07-14 13:09:57.000000000 -0400
+++ openldap-2.5.13-mod/servers/slapd/dn.c 2022-10-25 21:14:13.068933734 -0400
@@ -1188,6 +1188,11 @@
return 0;
}
+ /* dn is null */
+ if (dn->bv_val == NULL) {
+ return 0;
+ }
+
/* no rdn separator or escaped rdn separator */
if ( d > 1 && !DN_SEPARATOR( dn->bv_val[ d - 1 ] ) ) {
return 0;
=====
When I started creating a minimal config for this issue, things got stranger.
First, the config:
=====
include /usr/local/openldap-2.5.13/etc/openldap/schema/core.schema
database mdb
suffix "ou=Subordinate,dc=vt,dc=edu"
subordinate
rootdn "cn=Manager,dc=vt,dc=edu"
directory /usr/local/openldap-2.5.13/var/openldap-data/subordinate
maxsize 17179869184
index objectClass eq
index uid,entryCSN,entryUUID eq
database mdb
suffix "dc=vt,dc=edu"
rootdn "cn=Manager,dc=vt,dc=edu"
directory /usr/local/openldap-2.5.13/var/openldap-data/mdb
maxsize 17179869184
index objectClass eq
index uid,entryCSN,entryUUID eq
=====
The LDIF:
=====
dn: dc=vt,dc=edu
objectClass: dcObject
objectClass: organization
o: Virginia Tech
dc: vt
structuralObjectClass: organization
entryUUID: e906e392-731f-1034-98c4-c3e119ef52ff
creatorsName: cn=Manager,dc=vt,dc=edu
createTimestamp: 20150409161915Z
entryCSN: 20150409161915.467619Z#000000#000#000000
modifiersName: cn=Manager,dc=vt,dc=edu
modifyTimestamp: 20150409161915Z
contextCSN: 20221025003300.622285Z#000000#000#000000
dn: ou=Subordinate,dc=vt,dc=edu
objectClass: dcObject
objectClass: organizationalUnit
dc: vt
ou: subordinate
structuralObjectClass: organizationalUnit
entryUUID: 40b0b450-7321-1034-9e54-3f41091a54c5
creatorsName: cn=Manager,dc=vt,dc=edu
createTimestamp: 20150409162852Z
entryCSN: 20150409162852.039034Z#000000#000#000000
modifiersName: cn=Manager,dc=vt,dc=edu
modifyTimestamp: 20150409162852Z
=====
Unfortunately, that config and LDIF did not result in a segfault, but I noticed
that in my LDIFs that do, there is data after the subordinate entry, but that
data is commented out. Adding a small comment did not affect things, but adding
a large comment at the end of the LDIF did (4113 characters):
=====
#000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a
=====
If you remove the 'a' from the end of that comment, there is no segfault.
Note that this is sporadic, so I'm running in a loop to detect it:
for i in {1..10}; do rm /usr/local/openldap-2.5.13/var/openldap-data/*/*.mdb;
slapadd -q -w -b dc=vt,dc=edu -l ./minimal.ldif; done;
This also seems to be the case with entries after the subordinate entry that
have long attribute values (1027 characters, only tested with dc):
=====
dn: ou=1,dc=vt,dc=edu
objectClass: dcObject
objectClass: organizationalUnit
dc:
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a
ou: 1
structuralObjectClass: organizationalUnit
entryUUID: 40b0b450-7321-1034-9e54-3f41091a54c5
creatorsName: cn=Manager,dc=vt,dc=edu
createTimestamp: 20150409162852Z
entryCSN: 20150409162852.039034Z#000000#000#000000
modifiersName: cn=Manager,dc=vt,dc=edu
modifyTimestamp: 20150409162852Z
=====
Remove the 'a' from the end of dc, and no segfault.
I hope that's enough information to recreate this issue. I'm still looking at
it, but I haven't found the root cause yet.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9937
Issue ID: 9937
Summary: slapd buffer overflow in put_simple_filter()
Product: OpenLDAP
Version: 2.6.3
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: kimjuhi96(a)snu.ac.kr
Target Milestone: ---
Running this results in heap buffer overflow.
./servers/slapd/slapd -T c -a=
SUMMARY: AddressSanitizer: heap-buffer-overflow
(/home/juhee/project/foxfuzz/programs/network/openldap-test/servers/slapd/slap
d+0x726702)
Shadow bytes around the buggy address:
0x0c047fffcb10: fa fa 00 07 fa fa 00 00 fa fa 03 fa fa fa 00 05
0x0c047fffcb20: fa fa 02 fa fa fa 02 fa fa fa 03 fa fa fa 07 fa
0x0c047fffcb30: fa fa 02 fa fa fa 03 fa fa fa 06 fa fa fa 00 03
0x0c047fffcb40: fa fa 00 06 fa fa 00 02 fa fa 00 01 fa fa 00 04
0x0c047fffcb50: fa fa 00 00 fa fa 00 fa fa fa 00 02 fa fa 02 fa
=>0x0c047fffcb60: fa[fa]02 fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fffcb70: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fffcb80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fffcb90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fffcba0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fffcbb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==2262407==ABORTING
Breakpoint 1, 0x00005555556ca320 in __asan_report_load1 ()
gdb-peda$ bt
#0 0x00005555556ca320 in __asan_report_load1 ()
#1 0x0000555555c7a703 in put_simple_filter ()
#2 0x0000555555c7a309 in ldap_pvt_put_filter ()
#3 0x000055555588ca2b in str2filter_x ()
#4 0x000055555588ced4 in str2filter ()
#5 0x0000555555a31b61 in slap_tool_init ()
#6 0x0000555555a2e34d in slapcat ()
#7 0x0000555555708e1f in main ()
#8 0x00007ffff78cc083 in __libc_start_main (main=0x555555706ef0 <main>,
argc=0x4, argv=0x7fffffffdfc8,
init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>,
stack_end=0x7fffffffdfb8)
at ../csu/libc-start.c:308
#9 0x000055555561011e in _start ()
--
You are receiving this mail because:
You are on the CC list for the issue.