openldap-bugs

openldap-bugs@openldap.org

1 participants
21046 discussions

[Issue 10390] New: ldif_parse_line2 calculates an incorrect length of the attribute type
by openldap-its＠openldap.org 04 Nov '25

04 Nov '25

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 2

[Issue 10388] New: ldif_parse_line2 is not compliant with RFC2849
by openldap-its＠openldap.org 04 Nov '25

04 Nov '25

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 5

[Issue 10353] New: No TLS connection on Windows because of missing ENOTCONN in socket.h
by openldap-its＠openldap.org 04 Nov '25

04 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=10353 Issue ID: 10353 Summary: No TLS connection on Windows because of missing ENOTCONN in socket.h Product: OpenLDAP Version: 2.6.10 Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: julien.wadel(a)belledonne-communications.com Target Milestone: --- On Windows, the TLS connection cannot be done and we get the connection error: Can't contact LDAP server. => Connections are done with WSAGetLastError(). After getting WSAEWOULDBLOCK, the connection is not restart because of the state WSAENOTCONN that is not known. OpenLDAP use ENOTCONN that is set to 126 by "ucrt/errno.h" while WSAENOTCONN is 10057L. Adding #define ENOTCONN WSAENOTCONN like for EWOULDBLOCK resolve the issue. Reference commit on external project: https://gitlab.linphone.org/BC/public/external/openldap/-/commit/62fbfb12e8… -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10401] New: liblber: undefined shift of -1 in ber_decode_int()
by openldap-its＠openldap.org 04 Nov '25

04 Nov '25

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 5

[Issue 10400] New: NULL pointer deref in ldap_parse_result
by openldap-its＠openldap.org 04 Nov '25

04 Nov '25

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 3

[Issue 10381] New: Logformat config is broken
by openldap-its＠openldap.org 04 Nov '25

04 Nov '25

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 6

[Issue 10399] New: pw-pbkdf2.so iterations parameter checks for wrong argc
by openldap-its＠openldap.org 04 Nov '25

04 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=10399 Issue ID: 10399 Summary: pw-pbkdf2.so iterations parameter checks for wrong argc Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: jj+openldap(a)sft.lol Target Milestone: --- f602563bf4a9512885c8e3488d03b3f812cf42d9 introduced a pw-pbkdf2.so argument for specifying the number of hashing rounds. this contains a bug since the argc is 1 instead of 2 when passing one argument to the module - so the custom iterations are never considered (except when passing a first bogus argument and the iterations as second :) Background: We're integrating the pbkdf2-iteration configuration patch in Ubuntu https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/2125685 I've also just created an account on your gitlab instance - would be great if it was approved :) -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10379] New: lastbind change prevents ppolicy response from reaching accesslog
by openldap-its＠openldap.org 04 Nov '25

04 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=10379 Issue ID: 10379 Summary: lastbind change prevents ppolicy response from reaching accesslog 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 "lastbind on" and ppolicy are configured together, the pwdLastSuccess update triggers an accesslog entry (using op->o_time, op->o_tincr), then ppolicy_bind_response issues its own modification and since the time was copied in lastbind, an entry of the same name already exists. This means the ppolicy change is lost (and e.g. won't replicate). Note that slapo-lastbind (=the contrib overlay) probably has the same impact. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10169] New: Add support for token only authentication with otp overlay
by openldap-its＠openldap.org 04 Nov '25

04 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=10169 Issue ID: 10169 Summary: Add support for token only authentication with otp overlay Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Currently the OTP overlay is password + token. It would be nice to be able to configure it so it can run in a token only mode, similar to the slapo-totp overlay in contrib. This would allow us to have a project supported solution and retire that contrib module. -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 9564] New: Race condition with freeing the spilled pages from transaction
by openldap-its＠openldap.org 04 Nov '25

04 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=9564 Issue ID: 9564 Summary: Race condition with freeing the spilled pages from transaction Product: LMDB Version: 0.9.29 Hardware: Other OS: Mac OS Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: kriszyp(a)gmail.com Target Milestone: --- Created attachment 825 --> https://bugs.openldap.org/attachment.cgi?id=825&action=edit Free the spilled pages and dirty overflows before unlocking the write mutex The spilled pages (a transaction's mt_spill_pgs) is freed *after* a write transaction's mutex is unlocked (in mdb.master3). This can result in a race condition where a second transaction can start and subsequently assign a new mt_spill_pgs list to the transaction structure that it reuses. If this occurs after the first transaction unlocks the mutex, but before it performs the free operation on mt_spill_pgs, then the first transaction will end up calling a free on the same spilled page list as the second transaction, resulting in a double free (and crash). It would seem to be an extremely unlikely scenario to actually happen, since the free call is literally the next operation after the mutex is unlocked, and the second transaction would need to make it all the way to the point of saving the freelist before a page spill list is likely to be allocated. Consequently, this probably has rarely happened. However, one of our users (see https://github.com/DoctorEvidence/lmdb-store/issues/48 for the discussion) has noticed this occurring, and it seems that it may be particularly likely to happen on MacOS on the new M1 silicon. Perhaps there is some peculiarity to how the threads are more likely to yield execution after a mutex unlock, I am not sure. I was able to reproduce the issue by intentionally manipulating the timing (sleeping before the free) to verify that the race condition is technically feasible, and apparently this can happen "in the wild" on MacOS, at least with an M1. It is also worth noting that this is due to (or a regression from) the fix for ITS#9155 (https://github.com/LMDB/lmdb/commit/cb256f409bb53efeda4ac69ee8165a0b4fc1a277) where the free call was moved outside the conditional (for having a parent) that had previously never been executed after the mutex is unlocked, but now is called after the unlock. Anyway, the solution is relatively simple, the free call simply has to be moved above the unlock. In my patch, I also moved the free call for mt_dirty_ovs. I am not sure what OVERFLOW_NOTYET/mt_dirty_ovs is for, but presumably it should be handled the same. This could alternately be solved by saving the reference to these lists before unlocking, and freeing after unlocking, which would slightly decrease the amount of processing within the mutex guarded code. Let me know if you prefer a patch that does that. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs