- openldap-bugs - openldap.org

[Issue 10410] Buffer overflow in logging.c slapd module
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

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

1 0

[Issue 10366] New: Is 'second database definition & config directives' block duplicated?
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10366 Issue ID: 10366 Summary: Is 'second database definition & config directives' block duplicated? Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: truth_jp_4133(a)yahoo.co.jp Target Milestone: --- I have a question about an example of '6.1. Configuration File Format' section on this page (https://www.openldap.org/doc/admin26/slapdconfig.html). I think that 'second database definition & config directives' section is duplicated. Is the second 'second database definition & config directives' to be 'third database definition & config directives'? -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10345] New: Potential memory leak in function rbac_create_session
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10345 Issue ID: 10345 Summary: Potential memory leak in function rbac_create_session Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: alexguo1023(a)gmail.com Target Milestone: --- In `rbac_create_session`, we have the following code: ```c if ( rc < 0 ) { rs->sr_err = LDAP_OTHER; rs->sr_text = "internal error"; } else { (void)ber_flatten( ber, &rs->sr_rspdata ); rs->sr_rspoid = ch_strdup( slap_EXOP_CREATE_SESSION.bv_val ); // first rs->sr_err = LDAP_SUCCESS; } ber_free_buf(ber); done:; // always put the OID in the response: rs->sr_rspoid = ch_strdup( slap_EXOP_CREATE_SESSION.bv_val ); //second ``` The second `ch_strdup` at the `done` label overwrites `rs->sr_rspoid` without freeing the previous string, resulting in a memory leak. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10387] New: Reverse lookup does not work for IPv6 addresses proxied over IPv4
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10387 Issue ID: 10387 Summary: Reverse lookup does not work for IPv6 addresses proxied over IPv4 Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: +openldap(a)Eero.xn--Hkkinen-5wa.fi Target Milestone: --- I have an IPv4/IPv6 reverse proxy server which listens for ldap[s]:// connections and forwards them using the proxy procotol to an IPv4-only slapd server which listens for pldap[s]:// connections. The slapd server has the global olcReverseLookup setting set to TRUE. The reverse lookup works as expected if an LDAP client connects to the reverse proxy using IPv4. However, if the LDAP client connects to the reverse proxy using IPv6, the reverse lookup does not work. The slap_listener function in the servers/slapd/daemon.c file accepts a connection (https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_6_10/s…). Because the reverse proxy connects to the slapd server using the proxy protocol over IPv4, this fills the from variable with an IPv4 address and sets the len variable to the size of the struct sockaddr_in. This is correct. The slap_listener function detects that the connection is proxied (https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_6_10/s…) and uses the proxyp function to get the address of the LDAP client. This fills the from variable with an IPv4 or an IPv6 address (depending on whether the LDAP client used IPv4 or IPv6 to connect the reverse proxy) but does not update the len variable. The slap_listener function detects that reverse lookup is to be used (https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_6_10/s…) and used the ldap_pvt_get_hname function to get the reverse name (https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_6_10/s…) passing the address of the from variable, which may contain either an IPv4 or an IPv6 address, and the value of the len variable, which is equal to the size of the struct sockaddr_in. This is correct for IPv4 but not for IPv6. Either the slap_listener function or the proxyp function should update the value of the len variable. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10388] New: ldif_parse_line2 is not compliant with RFC2849
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10388 Issue ID: 10388 Summary: ldif_parse_line2 is not compliant with RFC2849 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: nivanova(a)symas.com Target Milestone: --- RFC2849: Any value that contains characters other than those defined as "SAFE-CHAR", or begins with a character other than those defined as "SAFE-INIT-CHAR", above, MUST be base-64 encoded. Other values MAY be base-64 encoded. SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B / %x3D-7F ; any value <= 127 except NUL, LF, CR, ; SPACE, colon (":", ASCII 58 decimal) ; and less-than ("<" , ASCII 60 decimal) However, if the value is not base64 encoded, ldif_parse_line2 (and consequently ldap_parse_ldif_record_x) uses isspace() to just skip any white-space characters at the beginning of at attribute value, icl. tabs. According to the RFC, however, such characters are acceptable. In addition, it does not return an error on LF or CR, just skips them. On the one hand, LDIFs are supposed to be human readable, and fixing this issue may lead to unexpected problems (e.g a stray tab being added to the attribute value). On the other hand, the standard does not exclude %x01-09 and %x0B-0C as valid characters for a non-encoded value. How should we proceed? -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10374] New: pcache olcOverlay={0}pcache,olcDatabase={2}sql,cn=config: template index 0 invalid
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10374 Issue ID: 10374 Summary: pcache olcOverlay={0}pcache,olcDatabase={2}sql,cn=config: template index 0 invalid Product: OpenLDAP Version: 2.6.8 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: bertrand(a)jacquin.bzh Target Milestone: --- Hi, As a follow-up from https://bugs.openldap.org/show_bug.cgi?id=10373, it appears that the configuration I had shared can be converted to olc with slaptest, however does not pass validation be loaded when the daemon start: ``` $ slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d $ slaptest -u -F /etc/openldap/slapd.d -d stats -d pcache unrecognized log level "pcache" (deferred) Total # of attribute sets to be cached = 16. Template: query template: (mail=) attributes: * + Template: query template: (objectClass=*) attributes: * + Template: query template: (objectClass=*) attributes: mail Template: query template: (objectClass=) attributes: ou cn givenName sn mail telephoneNumber description jpegPhoto objectClass Template: query template: (objectClass=*) attributes: ou cn givenName sn mail telephoneNumber description jpegPhoto objectClass Template: query template: (&(objectClass=)(&(jpegPhoto=*)(|(mail=)))) attributes: ou cn givenName sn mail telephoneNumber description jpegPhoto objectClass Template: query template: (objectClass=) attributes: ou cn givenName sn mail telephoneNumber jid description jpegPhoto objectClass Template: query template: (objectClass=*) attributes: ou cn givenName sn mail telephoneNumber jid description jpegPhoto objectClass Template: query template: (&(objectClass=)(&(jpegPhoto=*)(|(mail=)))) attributes: ou cn givenName sn mail telephoneNumber jid description jpegPhoto objectClass Template: query template: (jid=) attributes: jid config error processing olcOverlay={0}pcache,olcDatabase={2}sql,cn=config: template index 0 invalid (0->15) slaptest: bad configuration directory! ``` From the following slapd.conf: ``` overlay pcache pcache mdb 65536 16 1024 60 directory /var/lib/openldap-data/pcache pcacheMaxQueries 1024 # No TTR, see https://bugs.openldap.org/show_bug.cgi?id=10373 # Cache DN pcacheAttrset 0 1.1 pcacheTemplate (objectClass=) 0 3600 60 0 pcacheTemplate (objectClass=*) 0 3600 60 0 pcacheTemplate (&(objectClass=)(&(jpegPhoto=*)(|(mail=)))) 0 3600 60 0 pcacheAttrset 1 jid pcacheTemplate (jid=) 1 3600 60 0 pcacheAttrset 2 ou cn givenname sn mail telephonenumber jid description jpegphoto objectClass pcacheTemplate (&(objectClass=)(&(jpegPhoto=*)(|(mail=)))) 2 3600 60 0 pcacheTemplate (objectClass=*) 2 3600 60 0 pcacheTemplate (objectClass=) 2 3600 60 0 pcacheAttrset 3 ou cn givenname sn mail telephonenumber description jpegphoto objectClass pcacheTemplate (&(objectClass=)(&(jpegPhoto=*)(|(mail=)))) 3 3600 60 0 pcacheTemplate (objectClass=*) 3 3600 60 0 pcacheTemplate (objectClass=) 3 3600 60 0 pcacheAttrset 4 mail pcacheTemplate (objectClass=*) 4 3600 60 0 pcacheAttrset 5 * + pcacheTemplate (objectClass=*) 5 3600 60 0 pcacheTemplate (mail=) 5 3600 60 0 ``` The following olc configuration get generated ``` $ cat /etc/openldap/slapd.d/cn=config/olcDatabase={2}sql/olcOverlay={0}pcache/olcDatabase={0}mdb.ldif # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 20578f61 dn: olcDatabase={0}mdb objectClass: olcMdbConfig objectClass: olcPcacheDatabase olcDatabase: {0}mdb olcDbDirectory: /var/lib/openldap-data/pcache olcDbNoSync: FALSE olcDbMaxReaders: 0 olcDbMaxSize: 10485760 olcDbMode: 0600 olcDbSearchStack: 16 olcDbMaxEntrySize: 0 olcDbRtxnSize: 10000 structuralObjectClass: olcMdbConfig entryUUID: ff5661e1-1259-4408-89a8-68f3c1b36095 creatorsName: cn=config createTimestamp: 20250724124836Z entryCSN: 20250724124836.628803Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20250724124836Z $ cat /etc/openldap/slapd.d/cn=config/olcDatabase={2}sql/olcOverlay={0}pcache.ldif # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 a8cfafe8 dn: olcOverlay={0}pcache objectClass: olcOverlayConfig objectClass: olcPcacheConfig olcOverlay: {0}pcache olcPcache: mdb 65536 16 1024 60 olcPcacheAttrset: 1 jid olcPcacheAttrset: 2 ou cn givenName sn mail telephoneNumber jid description jp egPhoto objectClass olcPcacheAttrset: 3 ou cn givenName sn mail telephoneNumber description jpegPh oto objectClass olcPcacheAttrset: 4 mail olcPcacheAttrset: 5 * + olcPcacheTemplate: "(mail=)" 5 3600 60 0 0 olcPcacheTemplate: "(objectClass=*)" 5 3600 60 0 0 olcPcacheTemplate: "(objectClass=*)" 4 3600 60 0 0 olcPcacheTemplate: "(objectClass=)" 3 3600 60 0 0 olcPcacheTemplate: "(objectClass=*)" 3 3600 60 0 0 olcPcacheTemplate: "(&(objectClass=)(&(jpegPhoto=*)(|(mail=))))" 3 3600 60 0 0 olcPcacheTemplate: "(objectClass=)" 2 3600 60 0 0 olcPcacheTemplate: "(objectClass=*)" 2 3600 60 0 0 olcPcacheTemplate: "(&(objectClass=)(&(jpegPhoto=*)(|(mail=))))" 2 3600 60 0 0 olcPcacheTemplate: "(jid=)" 1 3600 60 0 0 olcPcacheTemplate: "(&(objectClass=)(&(jpegPhoto=*)(|(mail=))))" 0 3600 60 0 0 olcPcacheTemplate: "(objectClass=*)" 0 3600 60 0 0 olcPcacheTemplate: "(objectClass=)" 0 3600 60 0 0 olcPcachePosition: tail olcPcacheMaxQueries: 1024 olcPcachePersist: FALSE olcPcacheValidate: FALSE olcPcacheOffline: FALSE structuralObjectClass: olcPcacheConfig entryUUID: dbee2888-2741-4298-abc3-81ae4bd9433a creatorsName: cn=config createTimestamp: 20250724124836Z entryCSN: 20250724124836.628803Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20250724124836Z ``` Is this a known limitation at the moment ? Cheers, Bertrand -- You are receiving this mail because: You are on the CC list for the issue.

1 5

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

29 Jan '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 6

[Issue 10377] New: The words (addressbooks/addressbook) seems to be mismatched in the DIT example and the ACL example.
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10377 Issue ID: 10377 Summary: The words (addressbooks/addressbook) seems to be mismatched in the DIT example and the ACL example. Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: truth_jp_4133(a)yahoo.co.jp Target Milestone: --- In '8.4.8. Allowing entry creation' section, the DIT example is 'ou=addressbooks'. On the other hand, the ACL example is 'ou=addressbook,'. So the words (addressbooks/addressbook) seems to be mismatched in the DIT example and the ACL example. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10391] New: Add proper compiler/linker flag for threading support on HP-UX
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10391 Issue ID: 10391 Summary: Add proper compiler/linker flag for threading support on HP-UX Product: OpenLDAP Version: 2.6.10 Hardware: Other OS: Other Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: michael.osipov(a)innomotics.com Target Milestone: --- Created attachment 1085 --> https://bugs.openldap.org/attachment.cgi?id=1085&action=edit Patch against master If an application uses a thread-enabled library or the application itself is thread enabled it is imperative on HP-UX to use the -mt flag through out build. The compiler will transform into proper -D and -l flags. From the manpage: -mt Sets various -D flags to enable multi-threading. Also sets -lpthread. +Oopenmp automatically implies -mt. For details see HP C/aC++ Online Programmer's Guide. Find a Git-formatted patch attached. Sample output: libtool: link: /opt/aCC/bin/aCC -AC99 +We901 -o ldapsearch ldapsearch.o common.o ldsversion.o -L/opt/ports/lib/hpux32 ../../libraries/liblutil/liblutil.a ../../libraries/libldap/.libs/libldap.a -L/opt/ports/lib /var/tmp/ports/work/openldap-threading-hpux/libraries/liblber/.libs/liblber.a ../../libraries/liblber/.libs/liblber.a /opt/ports/lib/hpux32/libsasl2.so -ldl -lssl -lcrypto -mt -Wl,+b -Wl,/opt/ports/lib/hpux32 -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10349] New: Free ch_calloc-allocated memory in error paths
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10349 Issue ID: 10349 Summary: Free ch_calloc-allocated memory in error paths Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: alexguo1023(a)gmail.com Target Milestone: --- Created attachment 1078 --> https://bugs.openldap.org/attachment.cgi?id=1078&action=edit Free ch_calloc-allocated memory in error paths 1. In aa_operational, bv_allowed and bv_effective are allocated via ch_calloc. If ja == 0 or je == 0, these memory objects are never freed and do not escape the function, causing potential memory leak. 2. In memberof_db_init, the memory allocated by ch_calloc isn’t released on error paths, leading to another potential leak. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10390] New: ldif_parse_line2 calculates an incorrect length of the attribute type
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10390 Issue ID: 10390 Summary: ldif_parse_line2 calculates an incorrect length of the attribute type 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: nivanova(a)symas.com Target Milestone: --- When parsing a line containing an attribute name and a value, e.g "carLicence : 12344", ldif_parse_line2 calculates the type length incorrectly. It is not clear if this affects any existing code or tools at the moment, but should be fixed. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10360] New: delta-sync can apply old mods
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10360 Issue ID: 10360 Summary: delta-sync can apply old mods Product: OpenLDAP Version: 2.6.9 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- This might be related to #10358, but not sure. In delta MPR, if an older mod is received on an entry after a newer mod has already been applied by a local user, the older mod is applied and the newer mod is lost. The incoming replication ops are checked for freshness by check_csn_age() but that only checks the incoming cookieCSN against contextCSNs of the same SID. I.e., that check only prevents duplicate mods being replicated multiple times from the same remote provider. If check_csn_age() passes, then syncrepl_message_to_op() is invoked which just applies the mod. It doesn't check the mod or cookieCSN against the entry's current entryCSN. The code in syncrepl_op_mod() performs the checks we need. The code just needs to be pulled into a new function so it can be used in both places. -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 10367] New: Article for 'Asynchronous Metadirectory backend' seems to be typo.
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10367 Issue ID: 10367 Summary: Article for 'Asynchronous Metadirectory backend' seems to be typo. Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: truth_jp_4133(a)yahoo.co.jp Target Milestone: --- In the table of '6.2.2.1. backend <type>'section on this page(https://www.openldap.org/doc/admin26/slapdconfig.html), the description about asyncmet is 'a Asynchronous Metadirectory backend', but I think that this is 'an Asynchronous Metadirectory backend'. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10359] New: delta-MPR uses logbase for more than it documents
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10359 Issue ID: 10359 Summary: delta-MPR uses logbase for more than it documents Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- syncrepl logbase=<dn> is used not just for a syncrepl session (documented) but also for internal searches when it comes to delta-MPR conflict resolution. This is not documented so an admin doesn't know that the local accesslog DB needs to exist and have the same suffix. Either the documentation needs updating or a new configuration item needs to be added to allow an accesslog DB with a different suffix locally. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10380] New: file logger doesn't emit slapd startup/version info
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10380 Issue ID: 10380 Summary: file logger doesn't emit slapd startup/version info Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- When using syslog, a startup message is emitted which is useful in many different contexts: - signals a slapd restart to the admin - shows the actual version used - if a crash happened just before, there is no "stopped" message, this is a hint to anyone looking that something was not right and the slapd is not the same process - people writing log processing scripts (incident response) know when it's necessary to reset their state, again as it's a new process Because of the above, it feels like a regression to me. I guess we can just emit this info on logfile config handlers? This means startups and logfile switches are still handled as they used to in syslog and log rotation doesn't emit anything (making it easy and safe to just concatenate files). Yes, slapd logs its PID in most formats so restarts can be detected that way, but that's considerably harder to search for. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10304] New: Unable to remove item from directory as part of transaction if it is the last item in that directory
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10304 Issue ID: 10304 Summary: Unable to remove item from directory as part of transaction if it is the last item in that directory Product: OpenLDAP Version: 2.5.13 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: sophie.elliott(a)arcticlake.com Target Milestone: --- I am running my ldap server on Debian 11.3, with the mdb backend, using the backported openldap version 2.5.13. I am not 100% certain if this is an issue with OpenLDAP or liblmdb, but I have been running tests in the repo and it looks like the liblmdb tests work fine, so I think it's with OpenLDAP itself. I have been performing a transaction, and deleting entries from a directory during this transaction. This works fine if the item that I am deleting isn't the last entry in its directory, but when it is I get a MDB_NOTFOUND error on the commit transaction call and the delete doesn't go through. Here is an excerpt of the logs when this happens: ``` 67a64334.14e1fc32 0x766ad2a00700 => index_entry_del( 108, "accessGroupID=f23de82f-3a1c-4f88-86bb-bb07f9a0992d,o=[COMPANY],ou=accessGroups,dc=local,dc=[COMPANY],dc=com" ) 67a64334.14e21912 0x766ad2a00700 mdb_idl_delete_keys: 6c [62d34624] 67a64334.14e22812 0x766ad2a00700 <= index_entry_del( 108, "accessGroupID=f23de82f-3a1c-4f88-86bb-bb07f9a0992d,o=[COMPANY],ou=accessGroups,dc=local,dc=[COMPANY],dc=com" ) success 67a64334.14e23a91 0x766ad2a00700 mdb_delete: txn_commit failed: MDB_NOTFOUND: No matching key/data pair found (-30798) ``` Please let me know if I should submit this issue elsewhere, or if this is something that has already been fixed in a more recent version. I'm also happy to provide more details if necessary. Thank you! -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10400] New: NULL pointer deref in ldap_parse_result
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10400 Issue ID: 10400 Summary: NULL pointer deref in ldap_parse_result 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/8aae731b05bf423205db3d71aaedf18c Relevant stack trace: [Environment] ASAN_OPTIONS=exitcode=77 +----------------------------------------Release Build Stacktrace----------------------------------------+ Command: /mnt/scratch0/clusterfuzz/resources/platform/linux/unshare -c -n /mnt/scratch0/clusterfuzz/bot/builds/clusterfuzz-builds_curl_d1a7f12cc2e5055727a9c66d5eca203f3c8f5a6c/revisions/curl_fuzzer_ldap -rss_limit_mb=2560 -timeout=60 -runs=100 /mnt/scratch0/clusterfuzz/bot/inputs/fuzzer-testcases/crash-0f193edf6a069aa877a89a9f31c6b4d0c47ff028 Time ran: 0.0964963436126709 INFO: Running with entropic power schedule (0xFF, 100). INFO: Seed: 2389202903 INFO: Loaded 1 modules (166249 inline 8-bit counters): 166249 [0x55ca1b31da20, 0x55ca1b346389), INFO: Loaded 1 PC tables (166249 PCs): 166249 [0x55ca1b346390,0x55ca1b5cfa20), /mnt/scratch0/clusterfuzz/bot/builds/clusterfuzz-builds_curl_d1a7f12cc2e5055727a9c66d5eca203f3c8f5a6c/revisions/curl_fuzzer_ldap: Running 1 inputs 100 time(s) each. Running: /mnt/scratch0/clusterfuzz/bot/inputs/fuzzer-testcases/crash-0f193edf6a069aa877a89a9f31c6b4d0c47ff028 AddressSanitizer:DEADLYSIGNAL ================================================================= ==402==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x55ca1ae33b22 bp 0x7ffd8c148e00 sp 0x7ffd8c148d00 T0) ==402==The signal is caused by a READ memory access. ==402==Hint: address points to the zero page. #0 0x55ca1ae33b22 in ldap_parse_result curl_fuzzer/build/openldap/src/openldap_external/libraries/libldap/error.c:264:26 #1 0x55ca1a3c0b45 in oldap_connecting curl/lib/openldap.c:844:10 #2 0x55ca1a25c34f in protocol_connecting curl/lib/multi.c:1794:14 #3 0x55ca1a25c34f in multi_runsingle curl/lib/multi.c:2510:16 #4 0x55ca1a25a985 in curl_multi_perform curl/lib/multi.c:2791:18 #5 0x55ca1a20c048 in fuzz_handle_transfer(fuzz_data*) curl_fuzzer/curl_fuzzer.cc:419:5 #6 0x55ca1a20afd7 in LLVMFuzzerTestOneInput curl_fuzzer/curl_fuzzer.cc:97:3 #7 0x55ca1a0a854d in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:619:13 #8 0x55ca1a0932c2 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:329:6 #9 0x55ca1a099190 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:865:9 #10 0x55ca1a0c4cc2 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10 #11 0x7d3b976eb082 in __libc_start_main /build/glibc-LcI20x/glibc-2.31/csu/libc-start.c:308:16 #12 0x55ca1a08c3ad in _start ==402==Register values: rax = 0x0000000000000000 rbx = 0x00007ffd8c148d00 rcx = 0x0000799b969e0e00 rdx = 0x0000000000000000 rdi = 0x0000799b969e0e00 rsi = 0x0000793b959d5920 rbp = 0x00007ffd8c148e00 rsp = 0x00007ffd8c148d00 r8 = 0x000055ca1b751a00 r9 = 0x00007fffffffff01 r10 = 0x00007fffffffff01 r11 = 0x0000000000000001 r12 = 0x0000793b956d2800 r13 = 0x0000000000000000 r14 = 0x0000000000000000 r15 = 0x0000000000000000 AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/mnt/scratch0/clusterfuzz/bot/builds/clusterfuzz-builds_curl_d1a7f12cc2e5055727a9c66d5eca203f3c8f5a6c/revisions/curl_fuzzer_ldap+0x1411b22) ==402==ABORTING -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10343] New: Potential Memory Leak in function slap_uuidstr_from_normalized
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10343 Issue ID: 10343 Summary: Potential Memory Leak in function slap_uuidstr_from_normalized Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: alexguo1023(a)gmail.com Target Milestone: --- Created attachment 1070 --> https://bugs.openldap.org/attachment.cgi?id=1070&action=edit Patch: Change 1 to -1. In function slap_uuidstr_from_normalized, the code allocates a new `struct berval` with ```c new = (struct berval *)slap_sl_malloc(sizeof(struct berval), ctx); ``` and then attempt to allocate `new->bv_val`. If that second allocation fails, it sets `rc = 1` and jumps to the `done` cleanup label. However, the cleanup code only runs when `rc == -1`, so the memory pointed by `new` is never freed, causing a memory leak. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10433] New: Copyright update to 2026
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10433 Issue ID: 10433 Summary: Copyright update to 2026 Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Update copyright to 2026 -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10347] New: Fix a memory leak in function comp_convert_asn_to_ldap
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10347 Issue ID: 10347 Summary: Fix a memory leak in function comp_convert_asn_to_ldap Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: alexguo1023(a)gmail.com Target Milestone: --- Created attachment 1076 --> https://bugs.openldap.org/attachment.cgi?id=1076&action=edit Patch: Fix a memory leak in function comp_convert_asn_to_ldap In function comp_convert_asn_to_ldap, the bv->bv_val is allocated in 3 places: case BASICTYPE_BOOLEAN: bv->bv_val = (char*)malloc( 5 ); case BASICTYPE_INTEGER: bv->bv_val = (char*)malloc( INITIAL_ATTR_SIZE ); case BASICTYPE_ENUMERATED: bv->bv_val = (char*)malloc( INITIAL_ATTR_SIZE ); When csi->csi_syntax != NULL and csi->csi_syntax->ssyn_pretty != NULL, bv->bv_val is overwriten with bv->bv_val = prettied.bv_val;, causing porential memory leak. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10385] New: syncprov should use accesslog's rootDN when reading it
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10385 Issue ID: 10385 Summary: syncprov should use accesslog's rootDN when reading it Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- When replaying accesslog, syncprov runs a be_search, it should switch to using the appropriate rootDN for the database. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10381] New: Logformat config is broken
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10381 Issue ID: 10381 Summary: Logformat config is broken Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- After ITS#10140, logformat config parsing and emitting is broken. Some formats don't emit in cn=config, some abort. On Windows, log prefix is corrupted. Patch is being tested. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10392] New: back-ldap does not return a response if incorrect secprops is configured
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10392 Issue ID: 10392 Summary: back-ldap does not return a response if incorrect secprops is configured Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- If a non-existent secprops mechanism is configured as part of a back-ldap idassert-bind directive, back-ldap does not return a response to the following requests, leaving the client waiting. In the same case meta and asyncmeta would return an LDAP error. My guess is failure to establish the target connection is handled incorrectly in that code path. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10348] New: Free ch_malloc-allocated memory in error paths
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10348 Issue ID: 10348 Summary: Free ch_malloc-allocated memory in error paths Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: alexguo1023(a)gmail.com Target Milestone: --- Created attachment 1077 --> https://bugs.openldap.org/attachment.cgi?id=1077&action=edit Patch: Relase memory allocated from ch_malloc in 2 error handling branches. In ldap_back_monitor_ops_init and syncrepl_dirsync_message, memory allocated with ch_malloc was not freed when errors occurred. This adds two ch_free calls to ensure proper cleanup in those branches. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10376] New: 'this' seems to be duplicated in '8.4.5. Managing access with Groups' section
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10376 Issue ID: 10376 Summary: 'this' seems to be duplicated in '8.4.5. Managing access with Groups' section Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: truth_jp_4133(a)yahoo.co.jp Target Milestone: --- At the sentense 'One can then grant access to the members of this this group by adding appropriate by group clause to an access directive in slapd.conf(5).' in '8.4.5. Managing access with Groups' section, 'this' seems to be duplicated. https://www.openldap.org/doc/admin26/access-control.html -- 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