openldap-bugs February 2023

openldap-bugs@openldap.org

2 participants
132 discussions

[Issue 9045] Crashes in cn=config (test050)
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

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.

1 0

[Issue 9931] New: test079 broken on MacOSX
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

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.

1 12

[Issue 9991] New: slapd may close a connection twice
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

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.

1 4

[Issue 9955] UTF8bvnormalize() overruns
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

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.

1 0

[Issue 9940] New: slapadd segfault with -w on a subordinate database
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

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.

1 6

[Issue 9937] New: slapd buffer overflow in put_simple_filter()
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

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.

1 5

[Issue 9935] New: buffer overflow in UTF8StringValidate
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9935 Issue ID: 9935 Summary: buffer overflow in UTF8StringValidate 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: --- I get a heap buffer overflow running this on the latest openldap on git. Built with CFLAGS="-fsanitize=address" using clang 15. ./servers/slapd/slapd $(python2 -c 'print("-Td \x4c\x3d\xc2\x8c\xf0\xf0")') SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/juhee/project/foxfuzz/programs/network/openldap-ori/servers/slapd/slapd +0x3961ac) Shadow bytes around the buggy address: 0x0c047fffcb00: fa fa 00 06 fa fa 00 00 fa fa 00 07 fa fa 00 00 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[05]fa 0x0c047fffcb60: fa fa 00 00 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 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 ==2202218==ABORTING Stopped reason: SIGABRT __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. gdb-peda$ bt #0 __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x00007ffff78ca859 in __GI_abort () at abort.c:79 #2 0x00005555556eb04f in __sanitizer::Abort () at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_posix_libcdep.cpp:143 #3 0x00005555556e8aac in __sanitizer::Die () at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_termination.cpp:58 #4 0x00005555556c5dda in __asan::ScopedInErrorReport::~ScopedInErrorReport (this=0x7fffffffc4d6, __in_chrg=<optimized out>) at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/asan/asan_report.cpp:192 #5 0x00005555556c6461 in __asan::ReportGenericError (pc=<optimized out>, bp=0x7fffffffd140, sp=0x7fffffffd138, addr=0x602000025af5, is_write=is_write@entry=0x0, access_size=0x1, fatal=0x1, exp=<optimized out>) at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/asan/asan_report.cpp:199 #6 0x00005555556c99d6 in __asan::ReportGenericError (pc=<optimized out>, bp=bp@entry=0x7fffffffd140, sp=sp@entry=0x7fffffffd138, addr=<optimized out>, is_write=is_write@entry=0x0, access_size=access_size@entry=0x1, exp=<optimized out>, fatal=0x1) at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_atomic_clang.h:74 #7 0x00005555556ca34c in __asan::__asan_report_load1 (addr=<optimized out>) at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:118 #8 0x00005555558ea1ad in UTF8StringValidate () #9 0x000055555581e5a7 in LDAPRDN_rewrite () #10 0x000055555581d059 in LDAPDN_rewrite () #11 0x0000555555820f7f in dnPrettyNormal () #12 0x0000555555a37d1d in slapdn () #13 0x000055555570901f in main () #14 0x00007ffff78cc083 in __libc_start_main (main=0x555555706ef0 <main>, argc=0x3, argv=0x7fffffffdfd8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffdfc8) at ../csu/libc-start.c:308 #15 0x000055555561011e in _start () at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_internal_defs.h:397 -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9930] New: test050 deadlock on BSD OSes
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9930 Issue ID: 9930 Summary: test050 deadlock on BSD OSes 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: quanah(a)openldap.org Target Milestone: --- Initially reported to me directly as an issue with NetBSD 9.1, I was able to reproduce this with FreeBSD 13.1 as well. Investigation ongoing. Running test050 in a loop eventually results in a deadlock in one of the 4 slapd provider processes. -- You are receiving this mail because: You are on the CC list for the issue.

1 15

[Issue 9898] New: slapd-addel.c contains invalid struct initialization which does not compile on HP-UX aCC
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9898 Issue ID: 9898 Summary: slapd-addel.c contains invalid struct initialization which does not compile on HP-UX aCC Product: OpenLDAP Version: 2.6.3 Hardware: All OS: Other Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: michael.osipov(a)siemens.com Target Milestone: --- My compiler (cc: HP C/aC++ B3910B A.06.29 [Oct 18 2016]) gives me: /opt/aCC/bin/aCC -Ae -g -I../../include -I../../include -I/opt/ports/include -I/opt/ports/include -c -o slapd-addel.o slapd-addel.c "slapd-addel.c", line 68: error #2029: expected an expression LDIFRecord record = {}; ^ "slapd-addel.c", line 70: error #2029: expected an expression struct berval bv = {}; ^ This is invalid C code, it can be easily solved by using "{0}" and the code does compile. -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 9892] New: LDAP_TXN_SPECIFY assumes cleanup responsibility for writes but never performs it
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9892 Issue ID: 9892 Summary: LDAP_TXN_SPECIFY assumes cleanup responsibility for writes but never performs it 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: --- When TXN extop is accepted and the client sends some write ops, the cleanup path is skipped within do_modify/do_add/... however the data is never actually freed when the transaction is being settled (regardless of whether it was committed successfully or aborted). Confirmed to happen with do_modify by tests/scripts/lloadd/test007-coherence, for others it's my assumption based on reading the code. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

← Newer
1
...
7
8
9
10
11
12
13
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2023