I think this has the same root cause judging from the trace.

{{{
==15075==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fc0582a9508 at pc 0x7fc07125ed74 bp 0x7fc0582a9310 sp 0x7fc0582a8ab8
WRITE of size 712 at 0x7fc0582a9508 thread T12
#0 0x7fc07125ed73 in ?? asan_rtl:0
#1 0x7fc070e3b803 in slapi_pblock_get /home/william/development/389ds/ds/ldap/servers/slapd/pblock.c:718:0
#2 0x7fc070d76bff in strncasecmp_fast /home/william/development/389ds/ds/ldap/servers/slapd/intrinsics.h:71:0
#3 0x4626c8 in ldapu_cert_to_user /home/william/development/389ds/ds/lib/ldaputil/certmap.c:1377:0
#4 0x41f5c3 in connection_free_private_buffer /home/william/development/389ds/ds/ldap/servers/slapd/connection.c:876:0
#5 0x425187 in op_copy_identity /home/william/development/389ds/ds/ldap/servers/slapd/connection.c:2127:0
#6 0x7fc06e26b5cb in _pt_root /usr/src/debug/nspr-4.13.0/pr/src/pthreads/../../../nspr/pr/src/pthreads/ptthread.c:216:0
#7 0x7fc06e02b6f9 in start_thread /usr/src/debug/glibc-2.24-256-g5140d03/nptl/pthread_create.c:333:0
#8 0x7fc06dd662ae in __GI___clone /usr/src/debug////////glibc-2.24-256-g5140d03/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:105:0

Address 0x7fc0582a9508 is located in stack of thread T12 at offset 408 in frame
#0 0x7fc070d76a0c in slapi_back_transaction_commit /home/william/development/389ds/ds/ldap/servers/slapd/backend.c:674:0

This frame has 2 object(s):
[32, 36) 'rc'
[96, 808) 'pb' <== Memory access at offset 408 partially overflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
(longjmp and C++ exceptions are supported)
Thread T12 created by T0 here:
#0 0x7fc071248458 in pthread_create asan_rtl:0
#1 0x7fc06e26b2aa in _PR_CreateThread /usr/src/debug/nspr-4.13.0/pr/src/pthreads/../../../nspr/pr/src/pthreads/ptthread.c:457:0

SUMMARY: AddressSanitizer: stack-buffer-overflow (/lib64/libasan.so.3+0x47d73)
Shadow bytes around the buggy address:
0x0ff88b04d250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff88b04d260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
0x0ff88b04d270: f1 f1 04 f4 f4 f4 f2 f2 f2 f2 00 00 00 00 00 00
0x0ff88b04d280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff88b04d290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0ff88b04d2a0: 00[f4]f4 f4 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff88b04d2b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff88b04d2c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff88b04d2d0: 00 00 00 f4 f4 f4 00 00 00 00 00 00 00 00 00 00
0x0ff88b04d2e0: 00 00 00 00 f1 f1 f1 f1 00 f4 f4 f4 00 00 00 00
0x0ff88b04d2f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
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
Heap right redzone: fb
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
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
==15075==ABORTING

}}}

I can't reproduce this now with the same test.

https://bugzilla.redhat.com/show_bug.cgi?id=1386445

So I can't reproduce this now on fedora, and I have removed the memset code anyway. I'm going to close this, and track upstream for any improvements.

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/2060

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.