openldap-bugs October 2026

openldap-bugs@openldap.org

1 participants
73 discussions

[Issue 10590] New: sssvlv rejects multiple sort keys with protocolError in OpenLDAP 2.6.15
by openldap-its＠openldap.org 09 Oct '26

09 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10590 Issue ID: 10590 Summary: sssvlv rejects multiple sort keys with protocolError in OpenLDAP 2.6.15 Product: OpenLDAP Version: 2.6.15 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: christian(a)roessner.email Target Milestone: --- Created attachment 1204 --> https://bugs.openldap.org/attachment.cgi?id=1204&action=edit repro.go: anonymous RootDSE one-key versus two-key sorting (go-ldap v3.4.14) OpenLDAP 2.6.15 with the sssvlv overlay rejects a valid server-side sorting control containing two keys with: LDAP Result Code 2 "Protocol Error": serverSort control: decoding error A single key succeeds. Two keys fail with and without the simple paged results control. Reproduced using go-ldap/v3 v3.4.14, including an anonymous RootDSE base search. Tested pairs: cn + uid and uniqueIdentifier + uid, with caseIgnoreOrderingMatch explicitly selected for both keys. The application binds before requesting its initial sorted page, so this presents to users as a connection failure despite successful authentication. Environment: OpenLDAP 2.6.15 in a Linux x86_64 container (chrroessner/openldap LTS), on an AlmaLinux 10.2 host; client Go / macOS x86_64. The configuration loads sssvlv and enables overlay sssvlv. No sort-key limit override is configured (default five). A pristine upstream build has not yet been run for comparison. REPRODUCTION The attached repro.go sends only anonymous RootDSE searches, without reading directory accounts or writing data. Run against a disposable local server with sssvlv registered and a localhost LDAP listener on port 1389: mkdir ldap-sort-repro && cd ldap-sort-repro go mod init example.org/ldap-sort-repro go get github.com/go-ldap/ldap/v3@v3.4.14 # Copy the attached repro.go into this directory. go run . Expected: valid one-key and two-key requests are accepted. Observed on 2.6.15: the one-key case succeeds; both two-key cases return the diagnostic above. SUSPECTED CAUSE In servers/slapd/overlays/sssvlv.c, build_key(), comparison of upstream tags OPENLDAP_REL_ENG_2_6_13 and OPENLDAP_REL_ENG_2_6_15 shows the closing ber_scanf(ber, "}") replaced with: if (( tag = ber_peek_tag( ber, &len )) != LBER_DEFAULT ) { rs->sr_text = "serverSort control: decoding error"; rs->sr_err = LDAP_PROTOCOL_ERROR; return rs->sr_err; } The parser still shares the enclosing SortKeyList BER cursor across keys. After the first valid key, the next key's SEQUENCE remains in the cursor, so this check rejects a valid second key. This source change matches the observed diagnostic. The initial sequence handling also changed from ber_scanf to ber_skip_tag. The intended validation appears to require enforcing the boundary of the current SortKey SEQUENCE, while permitting the next key in SortKeyList. Simply accepting arbitrary trailing BER would not be an appropriate fix. Source: https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_6_15/s… Potentially related: ITS#10564, which records the sss_parseCtrl tightening (RE26 commit 6c0323aa). This report concerns rejection of valid sibling sort keys, not the malformed-input issue reported there. The release branch and current master source inspected on 2026-09-14 contain the same build_key() end-of-input check. This is source inspection, not a master runtime test. No live comparison against 2.6.13 was performed, so this report does not claim a verified first affected release. TEMPORARY CLIENT MITIGATION On the exact diagnostic above, retry only an initial search (no active paging cookie) with the primary sort key alone. Preserve that key for subsequent pages and cursor release. This drops the UID tie-breaker for equal primary values. Other errors remain visible. Suggested regression coverage: two and three keys, optional orderingRule/reverseOrder, paging continuation and cursor release, plus malformed/trailing BER rejection. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10573] New: OpenLDAP 2.7.0 fails to build with MSVC when preprocessing symbol version maps
by openldap-its＠openldap.org 09 Oct '26

09 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10573 Issue ID: 10573 Summary: OpenLDAP 2.7.0 fails to build with MSVC when preprocessing symbol version maps Product: OpenLDAP Version: 2.7.0 Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: openldap-msvc-673e3a64ee4f43(a)emalupe.com Target Milestone: --- OpenLDAP 2.7.0 fails to build with MSVC while generating the liblber symbol version map. The regression appears to have been introduced by commit 8651f98a08c37bea6ee9be78acececd52bac66a0 (ITS#9739). The new rules in libraries/liblber/Makefile.in and libraries/libldap/Makefile.in invoke: $(CPP) -x c -o $@ $(LT_CPPFLAGS) $(srcdir)/$(SYMBOL_VERSION_SCRIPT).in The -x c option is specific to GCC/Clang. When Autoconf's configured C preprocessor is MSVC (cl -E), cl ignores -x and treats the following c as an input filename: cl : Command line warning D9002 : ignoring unknown option '-x' c1: fatal error C1083: Cannot open source file: 'c': No such file or directory make[2]: *** [Makefile:301: lber.map] Error 2 This was reproduced with OpenLDAP 2.7.0 and Visual Studio 2026/MSVC 14.51 on Windows. OpenLDAP 2.6.13 builds successfully with the same compiler setup because it does not preprocess these map files. The same non-portable invocation is present in both the liblber and libldap map-generation rules and remains in the current OPENLDAP_REL_ENG_2_7 and master branches. Could the hard-coded compiler language option be removed or replaced with a configure-detected, compiler-portable way to preprocess the .map.in files? -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 10600] New: Deferred referral work can be attached to the wrong LDAP request
by openldap-its＠openldap.org 09 Oct '26

09 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10600 Issue ID: 10600 Summary: Deferred referral work can be attached to the wrong LDAP request Product: OpenLDAP Version: 2.7.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: simon.pichugin(a)gmail.com Target Milestone: --- When two operations receive referrals to the same connection while an anonymous rebind is in progress, lconn_rebind_queue stores URL arrays without retaining the request that owns each deferred referral. When the queue is drained, it uses the request context performing the rebind, so a child search can be attached to the wrong operation. How to reproduce Start two asynchronous searches on one LDAP handle. Have the origin return referrals for both operations to the same target, timing the second referral so it arrives while the target connection is performing the first anonymous bind. Let the target accept the bind and return successful results for both referred searches. Operation A receives its final result, while operation B has no deliverable final result and reaches its caller-supplied timeout. We reproduced this using public asynchronous APIs on one LDAP handle. The target validated both child search IDs and base DNs. Operation A completed, but operation B had no deliverable final result and timed out. Short result client_search_ids=1,2 origin_search_ids=1,2 target_verified_anonymous_bind id=4 origin_sent_b_referral_during_a_bind target_child_search_ids=3,5 target_child_search_bases=dc=target-a,dc=target-b operation_a_result=101 errno=0 operation_b_result=0 errno=-5 expected_timeout=-5 The test was generated using AI, so I can't share it here as per OpenLDAP's Policy on AI Contributions. Hence, describing the process with words. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10610] New: If double free if ldapi: socket name is too long
by openldap-its＠openldap.org 09 Oct '26

09 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10610 Issue ID: 10610 Summary: If double free if ldapi: socket name is too long Product: OpenLDAP Version: 2.6.14 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: --- slap_get_listener_addresses() frees the *sal on error and then its caller does the same. slap_get_listener_addresses() should just zero it afterwards? Also the error message lacks a trailing newline. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10593] New: VLV response formatting can read past a stack buffer and crash ldapsearch
by openldap-its＠openldap.org 09 Oct '26

09 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10593 Issue ID: 10593 Summary: VLV response formatting can read past a stack buffer and crash ldapsearch Product: OpenLDAP Version: 2.7.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: simon.pichugin(a)gmail.com Target Milestone: --- Created attachment 1209 --> https://bugs.openldap.org/attachment.cgi?id=1209&action=edit full asan and search results print_vlv() formats the server-provided VLV contextID into a fixed stack buffer. If snprintf() truncates the output, its required length is passed to the LDIF writer, which reads past the end of the buffer. We reproduced this with an unmodified ldapsearch that explicitly requested server-side sorting on cn and a VLV window. The server verified both request controls, returned one valid entry, then returned SSS success and a valid VLV success response with a large server-defined contextID. A 16 KiB contextID produced an ASan stack-buffer-overflow. A 64 KiB contextID crashed a non-sanitized, optimized client with SIGSEGV in all five runs. This is different from the SSS case. A VLV contextID is an opaque value selected by the server, and the VLV specification does not set a size limit. The triggering response does not need to mismatch caller input or violate the defined control sequence. The client must opt into VLV, and a 64 KiB contextID is unusual. Short ASan trace ERROR: AddressSanitizer: stack-buffer-overflow READ of size 1 #0 ldif_sput_wrap libraries/libldap/ldif.c:622 #1 ldif_put_wrap libraries/libldap/ldif.c:705 #2 tool_write_ldif clients/tools/common.c:2791 #3 print_vlv clients/tools/common.c:2264 #4 tool_print_ctrls clients/tools/common.c:2781 SUMMARY: AddressSanitizer: stack-buffer-overflow libraries/libldap/ldif.c:622 in ldif_sput_wrap Short native trace Program received signal SIGSEGV, Segmentation fault. #0 ldif_sput_wrap libraries/libldap/ldif.c:579 #1 ldif_put_wrap libraries/libldap/ldif.c:705 #2 tool_write_ldif clients/tools/common.c:2791 #3 print_vlv clients/tools/common.c:2264 #4 tool_print_ctrls clients/tools/common.c:2781 #5 print_result clients/tools/ldapsearch.c:2426 #6 dosearch clients/tools/ldapsearch.c:1840 #7 main clients/tools/ldapsearch.c:1550 -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10607] New: slapd: use-after-free in config_back_delete/_modify/_modrdn with concurrent cn=config writes
by openldap-its＠openldap.org 09 Oct '26

09 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10607 Issue ID: 10607 Summary: slapd: use-after-free in config_back_delete/_modify/_modrdn with concurrent cn=config writes 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: coding(a)markus-mazurczak.de Target Milestone: --- Created attachment 1217 --> https://bugs.openldap.org/attachment.cgi?id=1217&action=edit Patch: re-resolve config entry after pause and write lock (against 2.6.13, -p1) SUMMARY ======= back-config resolves the target CfEntryInfo *before* it pauses the server. Another cn=config write runs to completion inside that window and frees the entry, so the first operation continues on freed memory. With two clients writing to cn=config concurrently, slapd reliably crashes with SIGSEGV. This is not a theoretical race. It is the blocking defect for using cn=config as the control plane of a multi-tenant directory service: every tenant we create or remove is a handful of cn=config writes, and two overlapping provisioning flows take the server down. ANALYSIS ======== config_back_modify, config_back_modrdn and config_back_delete all do: ce = config_find_base( cfb->cb_root, &op->o_req_ndn, &last, op ); ... cheap validation on ce ... slap_pause_server(); ldap_pvt_thread_rdwr_wlock( &cfb->cb_rwlock ); ... use ce ... In openldap-2.6.13 (servers/slapd/bconfig.c): function config_find_base slap_pause_server wlock config_back_modify 6364 6439 6446 config_back_modrdn 6525 6668 6675 config_back_delete 6791 6825 6828 Between the lookup and the pause, this thread holds no lock on the config tree. A second cn=config write that is already past its own pause completes, reaches ce->ce_entry->e_private = NULL; entry_free( ce->ce_entry ); ch_free( ce ); /* bconfig.c:6946 */ and the first thread then dereferences the freed CfEntryInfo at bconfig.c:6835. config_back_add is not affected: it resolves the entry after the lock, inside config_add_internal. The read paths are correct -- config_back_search and config_back_compare take cb_rwlock for reading *before* calling config_find_base. Note that the thread pool itself is fine. PAUSE_ARG(DO_PAUSE) subtracts ltp_pause, so a second pauser first goes GO_IDLE, waits out the running pause and only then pauses; assert(!pool->ltp_pause) in handle_pause() holds. The problem is purely the stale pointer taken before the pause. REPRODUCTION ============ Build slapd with AddressSanitizer (glibc; ASan does not work under musl): CFLAGS="-g -O1 -fno-omit-frame-pointer -fsanitize=address" \ LDFLAGS="-fsanitize=address" \ ./configure --enable-mdb=yes --enable-dynlist=yes --enable-spasswd \ --with-cyrus-sasl --with-tls=openssl --enable-crypt make depend && make Start slapd with a cn=config database, then run four concurrent loops that each add an olcDatabase=mdb entry, add an olcOverlay=dynlist child, delete olcRootPW, and delete both again. The crash appears within seconds. AddressSanitizer output: ==15==ERROR: AddressSanitizer: heap-use-after-free READ of size 4 at 0x5060000681a0 thread T11 #0 config_back_delete servers/slapd/bconfig.c:6835 #1 fe_op_delete servers/slapd/delete.c:181 #2 do_delete servers/slapd/delete.c:95 #3 connection_operation servers/slapd/connection.c:1137 freed by thread T9 here: #0 free #1 ber_memfree_x libraries/liblber/memory.c:152 #2 ch_free servers/slapd/ch_malloc.c:139 #3 config_back_delete servers/slapd/bconfig.c:6946 previously allocated by thread T2 here: #0 calloc #1 ber_memcalloc_x libraries/liblber/memory.c:283 #2 ch_calloc servers/slapd/ch_malloc.c:104 #3 config_add_internal servers/slapd/bconfig.c:5615 #4 config_back_add servers/slapd/bconfig.c:5849 Without the sanitizer, the stock 2.6.13 build dies with SIGSEGV after roughly 175 add/delete cycles under the same load. With the patch below applied, the same load ran 14402 cycles in 150 seconds with no crash and a clean ASan run. PATCH ===== Resolve the entry again once the pause and the write lock are held, and answer noSuchObject if it is gone. The pre-pause lookup is kept, so a request that is going to fail anyway still does not pause the whole server. The patch is attached as 0001-cn-config-resolve-entry-after-pause.patch and applies with -p1 to openldap-2.6.13. For config_back_modrdn the re-resolved entry's ce_type is compared with the validated one; ixold is derived from op->o_req_ndn, so it stays consistent. I am happy to adjust the approach -- taking cb_rwlock for reading around the pre-pause validation as well would close the (much narrower) window in which the early checks themselves touch a freed entry. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 10589] New: multiple issues with ppolicy rules and rehash in ppolicy
by openldap-its＠openldap.org 09 Oct '26

09 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10589 Issue ID: 10589 Summary: multiple issues with ppolicy rules and rehash in ppolicy Product: OpenLDAP Version: 2.7.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: david.coutadeur(a)gmail.com Target Milestone: --- Created attachment 1202 --> https://bugs.openldap.org/attachment.cgi?id=1202&action=edit OpenLDAP Configuration Hello, I have tested recently the new ppolicy features of OpenLDAP 2.7.1. Thanks for this great work! The new features sound really exciting. Nevertheless, I have encountered some issues during testing. As these are new features, I don't know if this is a misconfiguration problem coming from me, or if there are bugs. You can find attached the configuration and data I have used. 1. I noticed that pwdPolicySubentry as static attribute is now deprecated. How could we assign directly a specific policy to a user in the future? 2. Using olcPPolicyRuleGroupAttr attribute in a scope rule generates a coredump while OpenLDAP tries to evaluate the assigned ppolicy. (ie during user entry loading). See the configuration. 3. I tried to configure a regex rule for assigning password policies. OpenLDAP crashes when trying to compute the assigned ppolicy. (when searching a user entry matching the policy). Maybe I have not correctly defined the regex rule, but I found no concrete example of this in documentation or unit tests. 4. Trying to run OpenLDAP in debug mode with TRACE level. (-d -1), whith given configuration and data makes OpenLDAP crash at startup, with no special log. It is due to scope and regex rules, as when I remove them, OpenLDAP starts normally. 5. For pwdRehashOnBind feature, I didn't understand the "If pwdReset is set to "TRUE"" part in the man page. The current behaviour I observed is that when pwdReset is TRUE, the password is never rehashed. What is the intent here? 6. When I try to modify a password from a user having a directly assigned ppolicy (pwdPolicySubentry defined statically), the password is never rehashed. Thanks in advance for your help! -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 10605] New: slapo-auditlog creates the log file with insecure permissions (0666)
by openldap-its＠openldap.org 09 Oct '26

09 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10605 Issue ID: 10605 Summary: slapo-auditlog creates the log file with insecure permissions (0666) Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: dns.spiros(a)gmail.com Target Milestone: --- Created attachment 1216 --> https://bugs.openldap.org/attachment.cgi?id=1216&action=edit patch implementing the described change The auditlog overlay opens its log file with mode 0666: fd = open(ad->ad_logfile, flags, 0666); Combined with a typical process umask (e.g. 022), this commonly results in a file that is world-readable (0644) - and, with a permissive umask, can remain world-writable as literally requested. This is a real concern for two independent reasons: 1. Confidentiality: the audit log records the full LDIF of every Add/ Modify/Delete/ModRDN operation, including attribute values. In our own testing, this included userPassword hashes (SSHA) appearing in clear LDIF form inside the log file. A world-readable audit log exposes this to any local user, regardless of the LDAP-level ACLs protecting the same data inside the directory itself. 2. Integrity: mode 0666 as requested permits world-write. An audit trail that any local user can modify does not reliably serve its purpose - tampering or truncation by an unprivileged user should not be possible. Standard security guidance for audit logging (CIS Benchmarks, DISA STIG, PCI-DSS Requirement 10.5, ISO/IEC 27001 Annex A.12.4) consistently requires that audit logs be protected from unauthorized read and write access - not left to whatever the deploying administrator's umask happens to be. Attached is a patch (plain git diff) changing the requested mode to 0640 (owner read/write, group read, no access for others), hardcoded rather than left to umask, consistent with how other security-sensitive files (e.g. private keys) are typically created. Note: this is a behavior change for any existing deployment relying on broader access to the raw log file (e.g. a non-group member reading it directly) - such setups would need to adjust group membership or ACLs accordingly after upgrading. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10609] New: slapd SIGABRT/core dump when modifying olcRemoteAuthDNAttribute in cn=config for olcOverlay={0}remoteauth
by openldap-its＠openldap.org 09 Oct '26

09 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10609 Issue ID: 10609 Summary: slapd SIGABRT/core dump when modifying olcRemoteAuthDNAttribute in cn=config for olcOverlay={0}remoteauth Product: OpenLDAP Version: 2.6.8 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: alain.raimbault(a)thalesgroup.com Target Milestone: --- Vendor Escalation Report — OpenLDAP remoteauth crash & AD bind failures Vendor/Product: OpenLDAP (slapd + remoteauth overlay/module) Module: /usr/lib64/openldap/remoteauth.so.2.0.200 (packaged by openldap-servers) OS: RHEL/CentOS 9 (el9 based; from environment) Symptoms: slapd SIGABRT/core dump when modifying olcRemoteAuthDNAttribute in cn=config for olcOverlay={0}remoteauth AD authentication fails with LDAP bind error Invalid credentials (49) / AD data 52e for multiple username formats 1. Environment Details 1.1 Installed OpenLDAP RPMs markdown content_copy openldap-2.6.8-4.el9.x86_64 openldap-servers-2.6.8-2.el9.x86_64 openldap-clients-2.6.8-4.el9.x86_64 1.2 remoteauth module packaging markdown content_copy rpm -qf /usr/lib64/openldap/remoteauth.so.2.0.200 openldap-servers-2.6.8-2.el9.x86_64 1.3 Module binary location markdown content_copy /usr/lib64/openldap/remoteauth.so -> remoteauth.so.2.0.200 /usr/lib64/openldap/remoteauth.so.2.0.200 1.4 Shared library dependencies (From ldd) libldap.so.2, libsasl2.so.3, libssl.so.3, libcrypto.so.3, libevent-2.1.so.7, etc. 2. Configuration Under Investigation 2.1 Overlay entry (active config) Example retrieved via: markdown content_copy ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// \ -b 'olcOverlay={0}remoteauth,olcDatabase={2}mdb,cn=config' -s base \ '(objectClass=*)' '*' Key attributes observed: olcRemoteAuthDNAttribute: cn olcRemoteAuthDomainAttribute: associatedDomain (as per your dump) olcRemoteAuthMapping: ntdsi ldap://laselainfadc01p.ntdsi.airsystems.thales and mapping to ntdsi.airsystems.thales DC URL olcRemoteAuthTLS: tls_reqcert=never olcRemoteAuthStore: FALSE 2.2 User entry (local LDAP) User searched with: objectClass: domainRelatedObject associatedDomain: ntdsi plus cn and uid values Verified by: markdown content_copy ldapsearch -x -LLL -D 'cn=ldapadmin,...' -W \ -b 'cn=A0007972-R(a)rah-r.thales,ou=Users,...' \ -s base '(objectClass=*)' objectClass associatedDomain Result: objectClass: domainRelatedObject associatedDomain: ntdsi 3. Reproduction of the Crash (Primary Defect) 3.1 How to reproduce slapd is running with remoteauth overlay configured (operational at least prior to this change). Modify the overlay attribute: Change: olcRemoteAuthDNAttribute from cn to uid Example LDIF used: ldif content_copy dn: olcOverlay={0}remoteauth,olcDatabase={2}mdb,cn=config changetype: modify replace: olcRemoteAuthDNAttribute olcRemoteAuthDNAttribute: uid Applied with: bash content_copy ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f change-remoteauth-dnattribute-to-uid.ldif 3.2 Result ldapmodify returns: “Can't contact LDAP server (-1)” slapd.service fails with core-dump / SIGABRT 4. Crash Evidence (Backtrace) From coredumpctl info slapd stack trace (repeated across multiple dumps): Crash location: remoteauth_cf_gen (remoteauth.so.2 + 0x2aee) called from: config_set_vals → config_parse_add → remoteauth_cf_gen Relevant frames: markdown content_copy #5 slap_bv2ad #6 slap_str2ad #7 remoteauth_cf_gen (remoteauth.so.2 + 0x2aee) #8 config_set_vals #9 config_parse_add #10 config_modify_add... Signal: SIGABRT (signal 6) aborted by __assert_fail path 4.3 Service status snippet From systemctl status slapd: “Active: failed (Result: core-dump) … Main PID dumped, signal=ABRT” 5. Additional Observation: AD Bind Failures (Secondary Issue) Multiple direct AD DC bind tests all fail with: ldap_bind: Invalid credentials (49) Additional info: AcceptSecurityContext error, data 52e Tests performed against: ldap://laselainfadc01p.ntdsi.airsystems.thales Tried DN/username forms: A0007972-R(a)rah-r.thales a0007972-r a0007972-r(a)ntdsi.airsystems.thales NTDSI\a0007972-r DN-style bind attempts (e.g., cn=a0007972-r,ou=Users,...) All failed with data 52e. 6. Evidence of remoteauth module being loaded From config dump / module list: cn=module{0},cn=config includes olcModuleLoad: {0}remoteauth module path: /usr/lib64/openldap 7. Expected vs Actual Behavior Expected Changing olcRemoteAuthDNAttribute from cn to uid should: either succeed cleanly, or return a validation/config error to LDAP client slapd should never crash on a config value update. Actual slapd SIGABRTs and produces a core dump during config modify. Crash occurs inside remoteauth_cf_gen() and OpenLDAP attribute string parsing (slap_str2ad, slap_bv2ad). 8. Impact Any attempt to update olcRemoteAuthDNAttribute to uid breaks the LDAP server (core-dump). This prevents applying the likely correct attribute mapping for AD username derivation. In parallel, AD binds return 52e for all tested identifiers/password combinations, which remains unresolved. 9. Suggested Areas for Vendor Investigation Bug/defect in remoteauth overlay when processing olcRemoteAuthDNAttribute value uid especially during config generation (remoteauth_cf_gen) should validate/return error instead of triggering assert() and aborting Potential ABI/config parsing mismatch between: openldap vs openldap-servers builds (mixed releases) Validate correct handling of attribute types / syntax in config parsing: crash path suggests OpenLDAP attribute-name parsing (slap_str2ad / slap_bv2ad) is being fed invalid/unsupported content during overlay config generation 10. Files/Artifacts to Attach (for faster vendor triage) coredumpctl info slapd output(s) stack trace text (as included above) LDIF used for the config modify (the LDIF file contents) slapcat -n 0 section around: olcOverlay={0}remoteauth cn=module{0},cn=config rpm -qi for openldap-servers ldd /usr/lib64/openldap/remoteauth.so.2.0.200 output system logs around the modify attempt: journalctl -u slapd -b -n 200 --no-pager -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 10606] New: LDAP_OPT_DEFBASE can't be reset to NULL
by openldap-its＠openldap.org 09 Oct '26

09 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10606 Issue ID: 10606 Summary: LDAP_OPT_DEFBASE can't be reset to NULL Product: OpenLDAP Version: 2.6.14 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- If there is no ldo_defbase on the global context, it's impossible to unset a connection's defbase to the default (libldap tries to strdup the NULL pointer and checks for NULL, but that's the correct value here). -- You are receiving this mail because: You are on the CC list for the issue.

1 4

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2026