- openldap-bugs - openldap.org

[Issue 10528] New: core.ldif fails to load via "include:" in cn=config on Symas OpenLDAP 2.6.13-3 (RHEL 9)
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10528 Issue ID: 10528 Summary: core.ldif fails to load via "include:" in cn=config on Symas OpenLDAP 2.6.13-3 (RHEL 9) Product: OpenLDAP Version: 2.6.13 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: lucas.vicente(a)ebz.tec.br Target Milestone: --- Hello, We are experiencing an issue while trying to load the core.ldif schema default using the dynamic configuration (cn=config). When using the following in my LDIF: include: file:///opt/symas/etc/openldap/schema/core.ldif I get this error: olcAttributeTypes: value #48 olcAttributeTypes: Unexpected token before MUST c MAY ( searchGuide $ description ) ) slapadd: could not add entry dn="cn={0}core,cn=schema,cn=config" (line=14): olcAttributeTypes: Unexpected token before MUST c MAY ( searchGuide $ description ) ) Obs: If I create a slapd.conf that includes the core schema and run: slaptest -f slapd.conf -F /tmp/slapd.d It works without errors. However, when trying to load the same schema using slapadd + include: in cn=config, it fails. For reference, I tested the same steps on version 2.6.10 and it worked without errors. Steps to reproduce: Install Symas OpenLDAP 2.6.13 on RHEL 9 Try to load the core schema using: dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema include: file:///opt/symas/etc/openldap/schema/core.ldif Would you be able to verify this behavior? Thanks! -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10423] New: It is possible via cn=config to add an entry of one database type with the object class of another, causing OpenLDAP to crash
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10423 Issue ID: 10423 Summary: It is possible via cn=config to add an entry of one database type with the object class of another, causing OpenLDAP to crash Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- This happens specifically because the user by mistake attempts to create a meta database by specifying the object class for back-ldap. Since these share a lot of common attributes, schema checks do not fail. As a result, slapd initializes a meta database (based on olcDatabase value), but attempts to manipulate an initialized back-ldap database after that, and segfaults. Like this: dn: olcDatabase=meta,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: meta olcDbURI: "ldap://example.com" While it seems this is only possible for the proxy databases, we cannot rely that schema checks on attributes will fail for other database combinations, who knows what common attributes can be added or supplied in the future, we we have to fix this. The issue is reproducible via slapadd and at runtime with ldapadd. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10641] New: Missing bound check on X.509 SAN string before wildcard matching
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10641 Issue ID: 10641 Summary: Missing bound check on X.509 SAN string before wildcard matching Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: xfding(a)google.com Target Milestone: --- In tls_o.c:1082, https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… (sn[0] == '*') && (sn[1] == '.') was tested before checking ( sl > 1 ) Similarly, on 1191, https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… ( cnstr[0] == '*' ) && ( cnstr[1] == '.' ) also has a missing bound check ( cnlen > 1 ) Note that OpenSSL would stop null-terminating strings by default in the major releases. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10236] New: fragmentation makes mdb_page_alloc slow
by openldap-its＠openldap.org 14 Oct '26

14 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10236 Issue ID: 10236 Summary: fragmentation makes mdb_page_alloc slow Product: LMDB Version: 0.9.31 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: aalekseyev(a)janestreet.com Target Milestone: --- Created attachment 1022 --> https://bugs.openldap.org/attachment.cgi?id=1022&action=edit patch is relative to LMDB_0.9.31 It's a known problem that mdb_page_alloc can be slow when the free list is large and fragmented. [1] [2] [3] I'm not sure it's known *how* slow it can be. In our workload we saw a fragmented freelist leading to a pathological O(n^2) behavior. To handle a multi-page allocation we iterate loading chunks of the free list one by one, and at every iteration we do O(n) work to check if the allocation can succeed. Even small-ish allocations (tens of pages) are repeatedly hitting this edge case, with free list growing to ~1000000, and the outer loop taking ~2000 iterations (10^9 worth of work in total, just to allocate a few pages). Even though I'm sure there are ways to avoid hitting this pathological scenario so much (avoid values larger than 4k, or fix whatever causes fragmentation), it seems unacceptable to have a performance cliff this bad. I made a patch to make the allocation take ~O(n*log(n)), by loading and merging multiple chunks at once instead of doing it one-by-one. I'd appreciate it if someone could review the patch (attached), improve it, and/or come up with an alternative fix. The code in `midl.c` is kinda meme-y, including a contribution from GPT-4o, but it performs well enough to speed up our pathological workload by ~20x (which is still ~3x away from the non-fragmented case). Anyway, the main thing that warrants scrutiny is the change in `mdb.c`: I understand very little about lmdb internals and I worry that loading multiple pages at once instead of one-by-one might break something. [1] issue #8664 [2] https://lists.openldap.org/hyperkitty/list/openldap-bugs@openldap.org/threa… [3] https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/… -- You are receiving this mail because: You are on the CC list for the issue.

1 14

[Issue 5738] back-monitor: registering a new backend (via moduleload) should add the corresponding entry in cn=monitor
by openldap-its＠openldap.org 14 Oct '26

14 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=5738 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |IN_PROGRESS --- Comment #5 from Howard Chu <hyc(a)openldap.org> --- https://git.openldap.org/openldap/openldap/-/merge_requests/941 Down the road we should also add support for deleting / unloading backends. The deleter can check to see if any databases have the backend in use, and return a failure in that case. Otherwise, it would be safe to unlink it from the list of backends and unload the module. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8617] Seg-fault while using meta database and rwm overlay together
by openldap-its＠openldap.org 14 Oct '26

14 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=8617 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Status|IN_PROGRESS |RESOLVED --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- RE27: bc937c33 by Ondřej Kuzník at 2026-10-14T22:44:08+00:00 ITS#8617 slapo-rwm: Never instantiate under back-meta -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10495] New: Environment variable for Systemd is ignored by configure
by openldap-its＠openldap.org 14 Oct '26

14 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10495 Issue ID: 10495 Summary: Environment variable for Systemd is ignored by configure Product: OpenLDAP Version: 2.6.13 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: openldap.aftermost863(a)passinbox.com Target Milestone: --- Hello, When using the configure script to generate the Makefile, the documentation in the --help option states that the environment variable 'systemdsystemunitdir' can be used to override the default system path for Systemd units. However, this does not work: if I export the variable with a valid existing path (e.g. 'export systemdsystemunitdir=/tmp/test') and then run ./configure, the variable is found but is ignored in the output variables and is therefore not used in the Makefile. config.log: ... ## ---------------- ## ## Cache variables. ## ## ---------------- ## ... ac_cv_env_systemdsystemunitdir_set=set ac_cv_env_systemdsystemunitdir_value=/tmp/test ... ## ----------------- ## ## Output variables. ## ## ----------------- ## ... systemdsystemunitdir='/usr/lib/systemd/system' ... The configure script seems to override that variable on line 23942: systemdsystemunitdir= I don’t quite understand why this line is there, and it seems suspicious to me. However, if I remove it and run ./configure again in the exact same shell, config.log now shows the correct path in the output variables, and the Makefile uses it correctly afterward: ... ## ---------------- ## ## Cache variables. ## ## ---------------- ## ... ac_cv_env_systemdsystemunitdir_set=set ac_cv_env_systemdsystemunitdir_value=/tmp/test ... pkg_cv_systemdsystemunitdir=/tmp/test ## ----------------- ## ## Output variables. ## ## ----------------- ## ... systemdsystemunitdir='/tmp/test' I had this issue on both Debian 13 (using bash) and Arch Linux (using zsh). -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 6761] contrib usn overlay broken
by openldap-its＠openldap.org 13 Oct '26

13 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=6761 --- Comment #2 from best(a)univention.de <best(a)univention.de> --- Thanks for this report. I wanted to experiment with it - and am affected as well. https://github.com/Free-IAM/freeiam/blob/v0.12.0/tests/Dockerfile#L24-L28 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8617] Seg-fault while using meta database and rwm overlay together
by openldap-its＠openldap.org 13 Oct '26

13 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=8617 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |IN_PROGRESS Ever confirmed|0 |1 Assignee|bugs(a)openldap.org |ondra(a)mistotebe.net --- Comment #5 from Ondřej Kuzník <ondra(a)mistotebe.net> --- https://git.openldap.org/openldap/openldap/-/merge_requests/939 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8149] nssov loginStatus doesn't play well with replication
by openldap-its＠openldap.org 09 Oct '26

09 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=8149 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |TEST --- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: d5734555 by Howard Chu at 2026-10-01T20:36:36+01:00 ITS#8149 slapo-nssov: fix bad commits from ITS#7518 Bad copy/paste in 1c99711ede25860b24750aab9c529a49c53756ae and incomplete config changes for new keywords 9504899a by Howard Chu at 2026-10-01T20:36:52+01:00 ITS#8149 slapo-nssov: add option to forward updates RE27: 3fb6f21d by Howard Chu at 2026-10-09T23:40:11+00:00 ITS#8149 slapo-nssov: fix bad commits from ITS#7518 Bad copy/paste in 1c99711ede25860b24750aab9c529a49c53756ae and incomplete config changes for new keywords f71a6fa3 by Howard Chu at 2026-10-09T23:40:18+00:00 ITS#8149 slapo-nssov: add option to forward updates -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8884] enabling overlay slapo-rwm makes 'entryDN' invisible
by openldap-its＠openldap.org 09 Oct '26

09 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=8884 --- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> --- RE27: b6894cad by Howard Chu at 2026-10-01T23:55:07+00:00 ITS#8884 slapo-rwm: don't strip entryDN in rwm_operational() It only needs to be stripped if it occurs in the main entry. In rs_operational it needs to be mapped, not stripped. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5500] comments in cn=config entries
by openldap-its＠openldap.org 08 Oct '26

08 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=5500 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=10619 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10401] New: liblber: undefined shift of -1 in ber_decode_int()
by openldap-its＠openldap.org 07 Oct '26

07 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10401 Issue ID: 10401 Summary: liblber: undefined shift of -1 in ber_decode_int() Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Report from curl project. Full info here https://gist.github.com/bagder/44a0711fa1989951f2a2395fe992530e Relevant stack trace: [Environment] UBSAN_OPTIONS=exitcode=77:print_stacktrace=1:silence_unsigned_overflow=1 +----------------------------------------Release Build Stacktrace----------------------------------------+ Command: /mnt/scratch0/clusterfuzz/resources/platform/linux/unshare -c -n /mnt/scratch0/clusterfuzz/bot/builds/clusterfuzz-builds_curl_4cc8f5a06444eef5b5b6682762bec8608d45b81b/revisions/curl_fuzzer_ldap -rss_limit_mb=2560 -timeout=60 -runs=100 /mnt/scratch0/clusterfuzz/bot/inputs/fuzzer-testcases/crash-1364ab2dfa120fe4460381a08f4f158f8d47a30c Time ran: 0.14911556243896484 INFO: Running with entropic power schedule (0xFF, 100). INFO: Seed: 1947994398 INFO: Loaded 1 modules (211579 inline 8-bit counters): 211579 [0x559e5bb87a40, 0x559e5bbbb4bb), INFO: Loaded 1 PC tables (211579 PCs): 211579 [0x559e5bbbb4c0,0x559e5bef5c70), /mnt/scratch0/clusterfuzz/bot/builds/clusterfuzz-builds_curl_4cc8f5a06444eef5b5b6682762bec8608d45b81b/revisions/curl_fuzzer_ldap: Running 1 inputs 100 time(s) each. Running: /mnt/scratch0/clusterfuzz/bot/inputs/fuzzer-testcases/crash-1364ab2dfa120fe4460381a08f4f158f8d47a30c decode.c:316:21: runtime error: left shift of negative value -1 #0 0x559e5b730e08 in ber_decode_int curl_fuzzer/build/openldap/src/openldap_external/libraries/liblber/decode.c:316:21 #1 0x559e5b730c5d in ber_get_int curl_fuzzer/build/openldap/src/openldap_external/libraries/liblber/decode.c:293:9 #2 0x559e5b6e60f3 in try_read1msg curl_fuzzer/build/openldap/src/openldap_external/libraries/libldap/result.c:592:7 #3 0x559e5b6e60f3 in wait4msg curl_fuzzer/build/openldap/src/openldap_external/libraries/libldap/result.c:393:12 #4 0x559e5b6e60f3 in ldap_result curl_fuzzer/build/openldap/src/openldap_external/libraries/libldap/result.c:120:7 #5 0x559e5af804d6 in oldap_connecting curl/lib/openldap.c:826:10 #6 0x559e5aead984 in protocol_connecting curl/lib/multi.c:1794:14 #7 0x559e5aead984 in multi_runsingle curl/lib/multi.c:2510:16 #8 0x559e5aeacd4f in curl_multi_perform curl/lib/multi.c:2791:18 #9 0x559e5ae7fb38 in fuzz_handle_transfer(fuzz_data*) curl_fuzzer/curl_fuzzer.cc:419:5 #10 0x559e5ae7eff0 in LLVMFuzzerTestOneInput curl_fuzzer/curl_fuzzer.cc:97:3 #11 0x559e5add608d in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:619:13 #12 0x559e5adc0e02 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:329:6 #13 0x559e5adc6cd0 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:865:9 #14 0x559e5adf2802 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10 #15 0x7c4beb5b7082 in __libc_start_main /build/glibc-LcI20x/glibc-2.31/csu/libc-start.c:308:16 #16 0x559e5adb9eed in _start SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior decode.c:316:21 -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 8884] enabling overlay slapo-rwm makes 'entryDN' invisible
by openldap-its＠openldap.org 01 Oct '26

01 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=8884 --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • 2b8cbe0a by Howard Chu at 2026-10-01T17:27:59+01:00 ITS#8884 slapo-rwm: don't strip entryDN in rwm_operational() It only needs to be stripped if it occurs in the main entry. In rs_operational it needs to be mapped, not stripped. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8149] nssov loginStatus doesn't play well with replication
by openldap-its＠openldap.org 01 Oct '26

01 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=8149 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |IN_PROGRESS --- Comment #1 from Howard Chu <hyc(a)openldap.org> --- Added forwarding option in https://git.openldap.org/openldap/openldap/-/merge_requests/931 We can't really make loginStatus operational since it's loaded from ldapns.schema. I mean, to do so requires hardcoding it into nssov's code. Which we could do, certainly. But it'll cause some confusion for existing configs, as we already saw when hardcoding ppolicy schema. The issue with opattrs / MMR replication needs some more thought. I've left it for now but perhaps we should just let it be treated as a completely ordinary mod. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8884] enabling overlay slapo-rwm makes 'entryDN' invisible
by openldap-its＠openldap.org 01 Oct '26

01 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=8884 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Status|CONFIRMED |RESOLVED --- Comment #3 from Howard Chu <hyc(a)openldap.org> --- Fixed in git 2b8cbe0aace6d7eea7a8b93a90afdbb94b81a0a9 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8884] enabling overlay slapo-rwm makes 'entryDN' invisible
by openldap-its＠openldap.org 01 Oct '26

01 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=8884 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |CONFIRMED --- Comment #2 from Howard Chu <hyc(a)openldap.org> --- Perhaps the code in rwm assumed the frontend would attach entryDN after the overlays transformations were completed. But clearly that's not what happens. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10286] New: ldap_pvt_gettime may result in "not new enough csn" problems in multi-thread case.
by openldap-its＠openldap.org 25 Sep '26

25 Sep '26

https://bugs.openldap.org/show_bug.cgi?id=10286 Issue ID: 10286 Summary: ldap_pvt_gettime may result in "not new enough csn" problems in multi-thread case. Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: 971748261(a)qq.com Target Milestone: --- Created attachment 1041 --> https://bugs.openldap.org/attachment.cgi?id=1041&action=edit the log of adding two entry which shows the time sequence. I used openldap as krb5's database, and openldap was deploymented in mirrormode. I tried to add kerberos principals via kadmin.local -q "addprinc -randkey principal. slapd log showed that the entry of kadmin/admin was added earlier than the entry of ossuser. But the csn of kadmin/admin was greater than ossuser. In this case, when the two entry began to sync to the other slapd server, ossuser was ignored because of "csn not new enough" -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 10598] New: Version 2.7 is both released in the past and a future release
by openldap-its＠openldap.org 22 Sep '26

22 Sep '26

https://bugs.openldap.org/show_bug.cgi?id=10598 Issue ID: 10598 Summary: Version 2.7 is both released in the past and a future release Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- The roadmap at https://www.openldap.org/software/roadmap.html contains: Future Minor Releases OpenLDAP 2.7 (Released August 2026) 2.7 cannot be at the same time a Future Release and Released in August 2026. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10601] GnuTLS TLS 1.2 renegotiation can spin in a nonblocking read callback
by openldap-its＠openldap.org 22 Sep '26

22 Sep '26

https://bugs.openldap.org/show_bug.cgi?id=10601 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |SUSPENDED Keywords|needs_review | Status|UNCONFIRMED |RESOLVED Group|OpenLDAP-devs | --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- patches welcome -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10591] New: slapo-syncprov frees modtarget and sessionlog nodes without checking that they were removed from their AVL tree, causing a use-after-free and SIGSEGV in the comparison callback
by openldap-its＠openldap.org 21 Sep '26

21 Sep '26

https://bugs.openldap.org/show_bug.cgi?id=10591 Issue ID: 10591 Summary: slapo-syncprov frees modtarget and sessionlog nodes without checking that they were removed from their AVL tree, causing a use-after-free and SIGSEGV in the comparison callback Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: bohdan.kmit(a)kiteworks.com Target Milestone: --- ## Symptom slapd terminates with SIGSEGV. Across 89 coredumps collected from several instances, 64 abort inside `malloc()` and 18 inside `free()` at unrelated allocation sites — glibc detecting an already-corrupt heap at whatever the process allocated next, reported variously as: ``` double free or corruption (out) malloc(): unaligned tcache chunk detected malloc(): unaligned fastbin chunk detected ``` Two cores caught the fault itself rather than a later detection. Both have no allocator frame and are structurally identical: ``` #0 sp_avl_cmp (c1=0x7f5778104590, c2=0x7f5f4954e13a) at syncprov.c:433 #1 ldap_avl_delete (root=..., data=c1, fcmp=sp_avl_cmp) at avl.c:199 #2 syncprov_op_cleanup (op, rs) at syncprov.c:1589 #3 slap_cleanup_play at result.c:607 #4 send_ldap_response at result.c:797 #5 slap_send_ldap_result at result.c:926 #6 mdb_add at add.c:389 #7 overlay_op_walk (which=op_add) at backover.c:706 #9 accesslog_response at accesslog.c:1966 #10 slap_response_play at result.c:573 #13 mdb_modify at modify.c:803 #16 syncrepl_message_to_op at syncrepl.c:3271 #17 do_syncrep2 at syncrepl.c:1555 #18 do_syncrepl at syncrepl.c:2197 ``` `si_addr` is `c2 + 0x10` in both. `modtarget` is ```c typedef struct modtarget { struct modinst *mt_mods; /* +0 */ struct modinst *mt_tail; /* +8 */ struct berval mt_dn; /* +16 -> bv_len */ ldap_pvt_thread_mutex_t mt_mutex; } modtarget; ``` so offset 16 is `mt_dn.bv_len`, exactly the field `sp_avl_cmp` reads at syncprov.c:433. Both `c2` values are not 8-byte aligned, so `si_mods` is holding freed and reused memory rather than a live `modtarget`. The path is a replicated MODIFY applied by syncrepl, whose response triggers the accesslog overlay to perform a nested internal ADD into the log database; that nested operation's cleanup walks `si_mods` and dereferences the stale node. ## Analysis `syncprov_op_cleanup()`, syncprov.c: ```c ldap_avl_delete( &si->si_mods, mt, sp_avl_cmp ); /* return value ignored */ ldap_pvt_thread_mutex_unlock( &si->si_mods_mutex ); ldap_pvt_thread_mutex_destroy( &mt->mt_mutex ); ch_free( mt->mt_dn.bv_val ); ch_free( mt ); ``` `ldap_avl_delete()` returns the node it removed, or NULL when the comparison does not locate it. Since `sp_avl_cmp` orders by `mt_dn`, a search can fail to find a target that is physically still in the tree, and can also match a different target that shares a DN. In either case `mt` is freed while still linked, and the next traversal dereferences it. Access to the tree is correctly serialised at all three sites (`ldap_avl_find` at :2787, `ldap_avl_insert` at :2861, `ldap_avl_delete` at :1589 all under `si_mods_mutex`), so this is a lifetime defect rather than a data race. Three related weaknesses in the same overlay: 1. `ldap_avl_insert()` at syncprov.c:2861 also ignores its return. A failed insert leaves `mt` unreferenced by the tree while `opc->smt` still points at it, so the later cleanup finds nothing to remove. 2. The `mt_mods` walk at syncprov.c:1574 and the `mt_mods` and `o_callback` walks in the abandon path at syncprov.c:2848 and :2856 have no termination condition: ```c for (m2 = &mt->mt_mods; ; m2 = &(*m2)->mi_next) { ``` If the entry is not on the list the loop runs off the end. This is the same pattern ITS#10408 corrected for `si_ops`, which was released in 2.6.15; the equivalent code two functions away was not changed. 3. The sessionlog trim at syncprov.c:1799 has the identical delete-then-free shape on a different tree: ```c ldap_tavl_delete( &sl->sl_entries, se, syncprov_sessionlog_cmp ); ch_free( se ); ``` One of the collected cores aborts in `syncprov_add_slog()` -> `ldap_tavl_insert()` at syncprov.c:1754, consistent with that tree also holding a freed node. The sessionlog is written on every logged operation, so on a busy provider it is exercised harder than `si_mods`. ## Same defect in two other overlays Found while auditing for the pattern; neither was loaded when the crash was observed, so these are reported from code inspection only. `slapo-pcache`, `remove_from_template()`: `ldap_avl_delete()` on `template->qbase` is unchecked and followed immediately by `ch_free( qc->qbase )`. The `ldap_tavl_delete()` on the scope tree above it is also unchecked, and both callers free `qc` only later, so a failed removal leaves either tree pointing at freed memory. `slapo-seqmod`, `seqmod_op_cleanup()`: the lookup result is validated with `assert( av != NULL )` and then dereferenced as `av->avl_data`. Under NDEBUG the assert is compiled out and the dereference faults instead. Its `ldap_avl_delete()` is also unchecked, though nothing is freed on that path. An audit of `servers/slapd` found no other unguarded `for (p = &head; ; p = &(*p)->next)` list walks, and `back-ldap/chain.c:1506` already checks its `ldap_tavl_delete()` return and logs on failure. ## Affected versions Verified byte-identical in `OPENLDAP_REL_ENG_2_6_15`, `OPENLDAP_REL_ENG_2_7_0`, `OPENLDAP_REL_ENG_2_7_1` and current `master`. Diffing `syncprov.c` between 2.6.15 and master produces no hunk touching `si_mods`, `modtarget`, `sp_avl_cmp`, `mt_mods`, `mt_tail` or `opc->smt`, and `avl.c` is unchanged. So there is no release to upgrade to. Crash observed on 2.6.15, x86-64, glibc, back-mdb, overlays `syncprov` and `accesslog` loaded, three-way multi-provider mesh with delta-syncrepl consumers reading the accesslog. Sustained write load of roughly 25 to 30 operations per second. ## Proposed fix Three patches, one per overlay: 1. **slapo-syncprov** — capture the return of `ldap_avl_delete()` and `ldap_tavl_delete()` and free only on an identity match, logging otherwise; bound the three list walks; report a failed `ldap_avl_insert()`. This converts a use-after-free into a bounded leak: a leaked `modtarget` is a few dozen bytes plus a DN, a dangling one takes the process down. 2. **slapo-pcache** — same guard on both removals in `remove_from_template()`. 3. **slapo-seqmod** — replace the assert with a real check that releases the mutex, completes the callback teardown and returns; report a failed `ldap_avl_delete()`. -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 10579] New: tlso_sb_{read,write} don't handle the opposite condition
by openldap-its＠openldap.org 18 Sep '26

18 Sep '26

https://bugs.openldap.org/show_bug.cgi?id=10579 Issue ID: 10579 Summary: tlso_sb_{read,write} don't handle the opposite condition Product: OpenLDAP Version: 2.7.0 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: --- With non-blocking BIO (lloadd), a SSL_write can error out with SSL_ERROR_WANT_READ and vice versa, e.g. at renegotiation or more points if TLS 1.3 is in place. Without knowing that, lloadd (or other applications if we ever say non-blocking OpenSSL use is supported) cannot make the right decisions, e.g. close a healthy connection. Of course lloadd also needs to expect this situation and arm the correct callback otherwise things get even worse. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10550] New: back ldap idletimeout broken
by openldap-its＠openldap.org 16 Sep '26

16 Sep '26

https://bugs.openldap.org/show_bug.cgi?id=10550 Issue ID: 10550 Summary: back ldap idletimeout broken 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: --- When an operation takes longer than idletimeout/conttl, back-ldap decides to terminate the connection. But if that connection is private, it doesn't do it right and asserts in ldap_back_conn_delete Two issues: - the TAINTED flag should not be set without the real state being set to match - a connection with an outstanding operation shouldn't be considered idle -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10566] A single unauthenticated LDAP request aborts the entire OpenLDAP slapd process
by openldap-its＠openldap.org 08 Sep '26

08 Sep '26

https://bugs.openldap.org/show_bug.cgi?id=10566 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Group|OpenLDAP-devs | -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10560] slapo-pcache caches a downstream answer at the DN that answer names, so a delegated-write user can forge another user's credentials
by openldap-its＠openldap.org 08 Sep '26

08 Sep '26

https://bugs.openldap.org/show_bug.cgi?id=10560 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|TEST |FIXED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs