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: [email protected]
Reporter: [email protected]
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.
