openldap-bugs

openldap-bugs@openldap.org

1 participants
21567 discussions

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

22 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 9

[Issue 10599] New: Compile error on Suse and older GCCs
by openldap-its＠openldap.org 22 Oct '26

22 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10599 Issue ID: 10599 Summary: Compile error on Suse and older GCCs Product: OpenLDAP Version: 2.7.0 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: dstoychev(a)symas.com Target Milestone: --- Created attachment 1213 --> https://bugs.openldap.org/attachment.cgi?id=1213&action=edit Diff of an example solution When building OpenLDAP on openSUSE 15.6 (which uses gcc 7) I get these errors: ``` tls_o.c: In function ‘tlso_ctx_init’: tls_o.c:547:7: error: a label can only be part of a statement and a declaration is not a statement X509 *cert = OSSL_STORE_INFO_get0_CERT( info ); ^~~~ tls_o.c:548:7: error: expected expression before ‘X509_STORE’ X509_STORE *store = SSL_CTX_get_cert_store( ctx ); ^~~~~~~~~~ tls_o.c:549:34: error: ‘store’ undeclared (first use in this function) if ( !X509_STORE_add_cert( store, cert ) ) { ^~~~~ tls_o.c:549:34: note: each undeclared identifier is reported only once for each function it appears in tls_o.c:757:6: error: a label can only be part of a statement and a declaration is not a statement X509 *cert = OSSL_STORE_INFO_get0_CERT(info); ^~~~ tls_o.c:758:6: error: expected expression before ‘int’ int is_ca = X509_check_ca( cert ); ^~~ tls_o.c:759:12: error: ‘is_ca’ undeclared (first use in this function); did you mean ‘ns_c_2’? if ( !is_ca && !SSL_CTX_use_certificate( ctx, cert )) { ^~~~~ ns_c_2 tls_o.c:777:6: error: a label can only be part of a statement and a declaration is not a statement X509_STORE *x509_s = SSL_CTX_get_cert_store( ctx ); ^~~~~~~~~~ ``` It does not happen on newer GCCs. This appears to be because on older GCC it is not allowed to have variable assignment right after a label and in tls_o.c there are `case` labels followed by a variable assignment (X509 *cert = OSSL_STO...) . One way to fix this is by putting the body of the case inside curly braces {}. Attaching an example diff that works to fix the issue for me. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10604] New: Consumer silently loses a contiguous block of entries under sustained write load via standard syncrepl (refreshAndPersist), N-Way Multi-Master
by openldap-its＠openldap.org 22 Oct '26

22 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10604 Issue ID: 10604 Summary: Consumer silently loses a contiguous block of entries under sustained write load via standard syncrepl (refreshAndPersist), N-Way Multi-Master Product: OpenLDAP Version: 2.6.10 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: dns.spiros(a)gmail.com Target Milestone: --- Summary (Architecture in brief: N-Way Multi-Master with 3 master nodes plus one read-only consumer in a hub-and-spoke arrangement, each node a separate VM with 4GB RAM / 2 vCPU on VMware Workstation - full detail under "Environment" below.) Under a sustained burst of Add operations on a single provider (roughly 500-1000+ operations at a rate of one every 5-50ms), one or more standard syncrepl consumers, in refreshAndPersist mode, silently fail to apply a contiguous block of entries - typically a few dozen, occasionally into the low hundreds. The missing entries are never retried: they are not present in the consumer's database, contextCSN on the consumer nonetheless advances to a value consistent with having processed them, and no error is logged. The condition has been observed to persist indefinitely until the affected slapd instance is restarted, at which point a full resync corrects it. The same underlying symptom (entries reported by a consumer as "<csn> not new enough, ignored" that were, per direct inspection, never actually applied by that consumer) has also been reproduced in a scenario involving an unclean shutdown ( kill -9 ) of two of three masters mid-write in an N-Way Multi-Master mesh, with one provider (captured live in its own log, loglevel: sync ) responding "nothing changed" / an empty-cookie refreshDelete to three simultaneous consumer sessions while its own local entry count was itself well behind the true dataset size. We are not certain of the exact internal root cause. We are reporting this because the minimal reproduction below is clean, small, and - in our testing - reliably triggers the symptom at or above roughly 1000 sequential Add operations on a single provider/single consumer pair, with no crash, no network impairment, and no other variable we have been able to identify as causal (see "Ruled out" below). Environment slapd version: 2.6.10+dfsg-0ubuntu0.24.04.1 (Ubuntu 24.04 LTS package: slapd -VV → @(#) $OpenLDAP: slapd 2.6.10+dfsg-0ubuntu0.24.04.1 (Sep 23 2025 16:26:39) $ ) Note on distribution packaging: this is the Ubuntu-maintained package, not a build from upstream OpenLDAP source. We are aware that issues specific to a distributor's packaging are generally referred back to the distributor, and we have not yet reproduced this against a vanilla build from OpenLDAP Git/release source. We are reporting it here first because the symptom appears to sit in core slapo-syncprov / syncrepl logic rather than anything Ubuntu-specific in the packaging, but we cannot rule out a packaging-specific contribution and would welcome guidance on whether a from-source reproduction is a prerequisite before this can be considered further. Backend: mdb (LMDB) Topology: N-Way Multi-Master, 3 provider/master nodes + 1 olcReadOnly: TRUE consumer-only node, in a hub-and-spoke arrangement (full mesh - refreshAndPersist between every pair of masters - with the read-only node as a spoke carrying three independent syncrepl directives, one toward each master) Hardware: 4 separate virtual machines (one per node), each 4GB RAM / 2 vCPU, on VMware Workstation Replication mode: standard syncrepl , type=refreshAndPersist . delta-syncrepl is deliberately not used. TLS/auth: mutual TLS, bindmethod=sasl saslmech=EXTERNAL , certificate CN mapped via olcAuthzRegexp to a per-node identity DN. Relevant olcSyncRepl directive (one per peer, rid varies): olcSyncRepl: rid=NNN provider=ldaps://<peer>:636 bindmethod=sasl saslmech=EXTERNAL searchbase="<basedn>" type=refreshAndPersist retry="5 10 10 30 60 120 300 +" timeout=5 network-timeout=5 keepalive=10:5:2 tls_cacert=<path> tls_cert=<path> tls_key=<path tls_reqcert=demand attrs="*,+" exattrs="memberOf" slapo-syncprov overlay parameters: olcSpSessionlog: 2000000 olcSpCheckpoint: 1000 10 (tested at both the above and a much tighter 50 1 - see "Ruled out") Other overlays in the stack (order matters, listed innermost first): memberof (index {1}, olcMemberOfRefInt: FALSE , exattrs="memberOf" on all syncrepl directives so it is computed locally and not replicated), refint (index {2}, referential integrity on member / uniqueMember / manager / owner , explicitly not on memberOf ), nestgroup (index {3}, search-time only, no writes), ppolicy (index {4}). syncprov sits outermost (index {0}). Search/size limits: verified unlimited both per-identity ( olcLimits matching the mTLS peer DNs used by syncrepl ) and at the frontend database level ( olcSizeLimit / olcTimeLimit on olcDatabase= {-1}frontend,cn=config ). Ruled out as a factor (see below). Minimal reproduction This is the cleanest form in which we have triggered the symptom: 1. A single provider (one master), a single persistent refreshAndPersist consumer. The other two masters in the mesh are stopped for this reproduction, to remove any multi-provider interaction as a variable. 2. Database freshly initialized/empty on both sides (a clean redeploy, not a preexisting dataset). 3. A namespace never used in any previous run (a fresh, timestamp-based DN prefix each run), to rule out any interaction with residual state or CSN history from prior test iterations. 4. From the provider, over a single reused connection ( ldapadd -x -c ), add N entries of class inetOrgPerson , one every 5ms (results identical at 50ms - see "Ruled out"): dn: uid=<prefix>.<i>,ou=People,<basedn> objectClass: top objectClass: inetOrgPerson uid: <prefix>.<i> cn: Test User <i> sn: Test userPassword: {SSHA}... 5. Wait for replication to settle (well past any configured retry interval), then count entries matching uid=<prefix>.* independently on the provider and on the consumer ( slapcat -a , not ldapsearch , to rule out any client-side search limit). Result across repeated runs: N=500 converges correctly in most runs, but not all (see "Notes on determinism" below). N=1000 and above have, in our testing, shown the symptom in the large majority of runs. When it occurs, the consumer is missing a contiguous range of entries (e.g. entries 474-504 of 2000 in one run; 1584-1604 of 2000 in a different run on a different consumer node; 299-320 of 1000 in a run using the never-before-used-namespace variant above). The size and position of the missing range vary between runs; its contiguity does not. Direct log evidence 1. A consumer receiving, but never applying, an entry - later resolved by a different peer within the same run (this run happened to be an N-Way mesh, so a second delivery path existed; in the single-provider minimal reproduction above, no such second path exists): syncrepl_message_to_entry: rid=101 DN: uid=crash.user.474,ou=people,dc (no corresponding be_add / syncrepl_entry follows for rid=101 at this point - the message is received and converted, but not applied) Several minutes later, in the same log, from a different provider session on the same consumer: syncrepl_message_to_entry: rid=103 DN: uid=crash.user.474,ou=people,dc syncrepl_entry: rid=103 uid=crash.user.474,ou=people,dc=example,dc=com syncrepl_entry: rid=103 be_add uid=crash.user.474,ou=people,dc=example do_syncrep2: rid=101 CSN too old, ignoring 20260921191238.368843Z#0000 do_syncrep2: rid=102 CSN too old, ignoring 20260921191238.368843Z#0000 2. A provider reporting "nothing changed" to three simultaneous consumers, including one whose own dataset was independently confirmed (via direct slapcat on that consumer, at the same moment) to be missing 163 of 500 expected entries: conn=1000 op=1 syncprov_op_search: no change, skipping log replay conn=1000 op=1 syncprov_op_search: nothing changed, finishing up initi conn=1000 op=1 syncprov_sendinfo: refreshDelete cookie= conn=1001 op=1 syncprov_op_search: no change, skipping log replay conn=1001 op=1 syncprov_op_search: nothing changed, finishing up initi conn=1001 op=1 syncprov_sendinfo: refreshDelete cookie= conn=1002 op=1 syncprov_op_search: no change, skipping log replay conn=1002 op=1 syncprov_op_search: nothing changed, finishing up initi conn=1002 op=1 syncprov_sendinfo: refreshDelete cookie= conn=1002 in this excerpt authenticated as the read-only consumer node (certificate CN mapped accordingly); the provider told it nothing had changed, and issued a refreshDelete with an empty cookie value. At the same wall-clock moment, slapcat -a run directly and locally on the provider itself returned 337 entries against an expected 500. The consumer's subsequent REFRESH_DELETE phase, taking the provider's "nothing changed / here is nothing" at face value, deleted entries the consumer had correctly received from a different, further-along provider - i.e. the incomplete provider's state propagated outward and actively destroyed correct data elsewhere in the mesh, rather than merely failing to advance it. Ruled out The following were each tested directly and found not to be causal: Unclean shutdown / kill -9 : the minimal reproduction above involves no crash of any kind. (A related, but distinct, amplification of the symptom has been observed specifically following kill -9 of two masters in a 3-master mesh - see log evidence #2 above - but the base symptom reproduces without any crash at all.) Network conditions: reproduces at full LAN speed with no induced latency/loss. A WAN emulation profile (25ms±1ms one-way, 0.1% loss via netem ) was used in some runs and disabled in others, with the same outcome either way. ss -ti on a stalled consumer-side connection during one incident showed a healthy TCP session (no retransmits, app_limited , RTT sub-millisecond) - the stall was not at the TCP layer. olcThreads : lowered from the default to 4 on all nodes; no change in outcome. Connection-level timeouts: timeout and network-timeout on the syncrepl directive (both apply only to initial connect/Bind, per slapd-config(5) , not to an established session); olcWriteTimeout (set to 30s server-wide); tcp-user-timeout was considered but not pursued once the TCP-layer health above was confirmed. None of the above affected the outcome. Clock skew: wall-clock time compared across all four nodes, dispatched in parallel via backgrounded SSH; maximum observed spread 123ms, most of which is attributable to SSH connection overhead itself. Reuse of DN namespace across test runs: reproduces with a namespace prefix that has never been used in any prior run (see "Minimal reproduction" above). olcLimits /search size limits: verified unlimited , both per-identity (the mTLS peer DNs used by the syncrepl sessions themselves) and at olcDatabase={-1}frontend,cn=config (i.e. cluster-default). No change in outcome with either configuration. Size of preexisting dataset: reproduces identically against a freshly initialized, otherwise-empty database. Write rate: 5ms and 50ms between successive Add operations produced the same outcome at the same volume thresholds. syncprov-checkpoint interval: tightened from 1000 10 to 50 1 with the affected pair of masters restarted cleanly beforehand; this did not measurably change the outcome across repeated runs. (We had hypothesized, based on the documented behavior that contextCSN is updated in memory on every write but only persisted to the on-disk checkpoint periodically or on clean shutdown, that an unclean shutdown recovering from a stale on-disk checkpoint might explain the crash- correlated variant specifically. Direct testing did not support this; we record the negative result for completeness.) Notes on determinism The symptom is not 100% deterministic at any volume we tested. At 2000 sequential Add operations it has occurred in the substantial majority of our runs; at 1000 in many but not all; at 500 only in a minority of runs, with most runs at that volume converging correctly and instantly (sub-second). We have not identified what distinguishes a failing run from a succeeding one at the same volume and otherwise-identical configuration; every variable we varied to try to explain this (see "Ruled out") produced no change we could attribute to it with confidence. We flag this explicitly because it is the main reason we have not been able to narrow this report further before submitting it. Related discussions we are aware of An openldap-technical mailing list thread from 2008-2009 describes what appears to be the same class of symptom - entries reported by a consumer as superseded ("too old") that were, in fact, never applied - attributed there to out-of-order commit-queue processing on the provider under concurrent writes, with a partial fix referenced against 2.4.11/2.4.16 and a further related ITS (#6619) mentioned as still open as of a 2011 follow-up. We have not been able to confirm whether that specific issue is fully resolved in 2.6.x or whether what we are seeing is a distinct, related condition. ITS #9538 (April 2021, "Accesslog entryCSN ordering is not always monotonous") documents non-monotonic entryCSN ordering under concurrent operations as a live concern in a more recent timeframe. We are aware of, and our architecture already follows, the guidance (Quanah Gibson-Mount, openldap-technical , 24 May 2024) that standard syncrepl is the recommended, safer replication mechanism for multi-provider environments in OpenLDAP 2.6+, in preference to delta-syncrepl . We note this because our minimal reproduction above is, if anything, a simpler case than the multi-provider scenario that guidance addresses (a single provider, a single consumer) and so does not appear to be excluded by it. What we are asking We are not confident enough in any single hypothesis to assert a root cause, and would welcome guidance on: 1. Whether this is a known, already-tracked issue (our searches of the mailing list and public ITS entries did not turn up an exact match, but we may have missed the right terms). 2. Whether a reproduction against a from-source build of current Git master (rather than the Ubuntu package) is a prerequisite for further triage, and if so we are willing to attempt it. 3. Any specific loglevel combination, beyond stats sync (already enabled throughout our testing), or any debugger/instrumentation approach the team would recommend to capture the provider-side state at the exact moment an entry is dropped, which we have not yet managed to capture directly (all evidence above is inferred from surrounding log lines, not a single line that directly shows the drop occurring). We can provide the complete Ansible automation used to build the test environment and drive these reproductions, full logs from any of the runs referenced above, and are happy to run additional targeted tests against specific hypotheses. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

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

22 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 5

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

22 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 4

[Issue 10612] New: olcLogFile not populated on slaptest -f slapd.conf
by openldap-its＠openldap.org 22 Oct '26

22 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10612 Issue ID: 10612 Summary: olcLogFile not populated on slaptest -f slapd.conf 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: --- Per title, put `logfile /path/to/slapd.log` and check `cn=config` entry, olcLogFile is missing. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

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

22 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 5

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

22 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 5

[Issue 10597] New: slapo-accesslog frees a shared `entryUUID` value from operations that do not hold the mutex guarding it, causing a double free and heap corruption. Introduced in 2.6.14 by the fix for ITS#10482.
by openldap-its＠openldap.org 22 Oct '26

22 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10597 Issue ID: 10597 Summary: slapo-accesslog frees a shared `entryUUID` value from operations that do not hold the mutex guarding it, causing a double free and heap corruption. Introduced in 2.6.14 by the fix for ITS#10482. Product: OpenLDAP Version: 2.6.14 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: --- Created attachment 1212 --> https://bugs.openldap.org/attachment.cgi?id=1212&action=edit Patch # Symptom `slapd` terminates with SIGSEGV under concurrent write and search load. glibc reports the corruption at whatever the process allocates next, so the message varies: ``` double free or corruption (out) malloc(): unaligned fastbin chunk detected malloc(): unaligned tcache chunk detected free(): invalid pointer ``` Of ten cores collected from one instance, nine abort inside `malloc()` or `calloc()` at unrelated allocation sites and carry no information about the origin. One caught the faulting free itself: ``` #4 free () #5 accesslog_response (op=<optimized out>, rs=...) at accesslog.c:2034 #6 ... #8 slap_send_ldap_result () ``` (line 2034 in 2.6.15; the equivalent is 2176 in current master.) # Analysis `accesslog_response()` ends with: ```c skip: if ( !BER_BVISNULL( &li->li_uuid ) ) { ber_memfree( li->li_uuid.bv_val ); BER_BVZERO( &li->li_uuid ); } if ( lo->mask & LOG_OP_WRITES ) { /* We haven't transitioned to li_log_mutex yet */ ldap_pvt_thread_mutex_unlock( &li->li_op_rmutex ); } return SLAP_CB_CONTINUE; ``` `li_uuid` is a field of the shared `log_info` instance, not of the operation. Access to it is asymmetric: * Write operations (`bi_op_add`, `bi_op_delete`, `bi_op_modify`, `bi_op_modrdn` → `accesslog_op_mod()`) acquire `li_op_rmutex` and populate `li_uuid` with `ber_dupbv()` while holding it. They still hold it on entry to `accesslog_response()`, free under it at `skip:`, and release it immediately after. This is correct. * Non-write operations (`bi_op_bind`, `bi_op_compare`, `bi_op_search`, `bi_extended` → `accesslog_op_misc()`) take no lock at all. `accesslog_response()` acquires `li_op_rmutex` for them only part-way through the function, and **all four `goto skip` sites precede that acquisition** (master: 1656, 1661, 1671, 1683 versus the lock at 1693). Such an operation therefore reaches `skip:` holding no lock, and frees a pointer it never set. The `goto skip` conditions reachable this way are: | site | condition | |------|-----------------------------------------------------| | 1656 | log database absent or not open | | 1661 | `op->o_dont_replicate` | | 1671 | `li_success` configured and the operation failed | | 1683 | operation not in `li_ops` and no matching `logbase` | Two consequences follow: 1. Two non-write operations completing concurrently both observe a non-NULL `li_uuid` and both call `ber_memfree()` on it — a double free. 2. A non-write operation can free it in the window between a write operation storing the value and that write operation taking ownership of it (master 1716–1718, under both mutexes). The write path then works with, and frees, a dangling pointer. Either way the allocator's free lists are corrupted, and the failure surfaces later at an unrelated allocation, which is why almost every core points somewhere innocent. The exposure depends strongly on configuration. With `olcAccessLogOps: writes`, searches are not in `li_ops`, so **every search** fails the test at 1673 and takes `goto skip` at 1683. A read-heavy workload therefore executes the unlocked free at close to search rate. Note that 1683 is unreachable for write operations, since `accesslog_op_mod()` applies the same test before registering the callback. Access to the tree of related state is otherwise correct: every use of `li_mincsn`, `li_sids` and `li_numcsns` in `log_old_lookup()`, `accesslog_purge()`, `accesslog_response()` and `accesslog_db_root()` is serialised by `li_log_mutex`, and no locked region in the file contains a `return` or `goto` that bypasses its unlock. `li_uuid` is the only unserialised mutation. # Regression The unconditional free was added by: ``` 5c4e7f2f1a ITS#10482 slapo-accesslog: do not leak entryUUID (2026-03-31) ab4e53e54b same, backported to the 2.6 branch ``` That commit consists solely of those four lines. It plugs a genuine leak but places the release on a path reachable without the mutex. # Affected versions | release | affected | |--------------|----------| | 2.6.13 | no | | 2.6.14 | yes | | 2.6.15 | yes | | 2.7.0, 2.7.1 | yes | | master | yes | Observed on 2.6.15, x86-64, glibc, back-mdb, with `syncprov` and `accesslog` on the same database and delta-syncrepl consumers reading the accesslog. # Reproduction Configuration: `accesslog` over back-mdb with `olcAccessLogOps: writes` and `olcAccessLogSuccess: TRUE`. Load: six concurrent MODIFY streams cycling over four DNs (to maximise same-target concurrency), two more spread over twenty DNs, one stream of ADDs of existing entries (returning `entryAlreadyExists`), and twelve concurrent search streams over the same subtree. Result: SIGSEGV within **13–24 seconds**, repeatably — effectively one crash per load application. Two observations that isolate the mechanism: * The **same write load with no search streams ran 300 seconds without a fault.** Searches are required, because only non-write operations take the unlocked path. * Instances receiving the identical replicated write stream but carrying **no local search traffic** ran 68 minutes without a fault, while an instance with local searches plus the same replicated writes crashed. `MALLOC_CHECK_` does not help: by the time of the second free the chunk has typically been handed to another allocation, so it is a valid live chunk and nothing is flagged at the free. # Proposed fix Free the value only on the path that owns it and already holds the mutex: ```diff skip: - if ( !BER_BVISNULL( &li->li_uuid ) ) { - ber_memfree( li->li_uuid.bv_val ); - BER_BVZERO( &li->li_uuid ); - } if ( lo->mask & LOG_OP_WRITES ) { + /* Only this path holds li_op_rmutex, which guards li_uuid */ + if ( !BER_BVISNULL( &li->li_uuid ) ) { + ber_memfree( li->li_uuid.bv_val ); + BER_BVZERO( &li->li_uuid ); + } /* We haven't transitioned to li_log_mutex yet */ ldap_pvt_thread_mutex_unlock( &li->li_op_rmutex ); } ``` Non-write operations never populate `li_uuid`, so they have nothing to release; the leak ITS#10482 addressed remains fixed for the write path, which is the only producer. Because every `goto skip` precedes the mutex acquisition, no path can now reach the label holding the lock without releasing it. # Related observation, not addressed by this patch `li_old` has the same missing release. `accesslog_op_mod()` assigns `li->li_old = entry_dup( e )` without freeing any previous value, `accesslog_response()` moves it out only on the non-skip path, and neither `skip:` nor `accesslog_db_destroy()` releases it. A write operation whose response takes `goto skip` therefore strands an `Entry`, which the next write overwrites and leaks. This requires `olcAccessLogOld` to be configured and is a leak only — no unserialised free, so no corruption. Reported for completeness rather than fixed here. -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 10621] New: back-sock: sock_over_op strips all callbacks
by openldap-its＠openldap.org 22 Oct '26

22 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10621 Issue ID: 10621 Summary: back-sock: sock_over_op strips all callbacks Product: OpenLDAP Version: 2.6.15 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: --- overlays set up callbacks to manage their own resources or undo changes to *op, this quietly skips them and might(/will) leave *op contents inconsistent. e.g. when coupled with pcache, ors_attrs ends up pointing to pcache-owned memory, freeing which out of turn is deadly. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs