openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

[Issue 10336] New: slapd crashes with segfault in mdb_delete.c on non-existent tree part deletion
by openldap-its＠openldap.org 14 May '25

14 May '25

https://bugs.openldap.org/show_bug.cgi?id=10336 Issue ID: 10336 Summary: slapd crashes with segfault in mdb_delete.c on non-existent tree part deletion 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: A.Asemov(a)edpnet.com Target Milestone: --- slapd crashes with segfault in mdb_delete.c on non-existent tree part deletion. Applies to 2.6.7, 2.6.8, 2.6.9 ---------- Prerequisites: ---------- - mdb backend - empty mdb database ---------- Sample reproducer: ---------- ldapdelete -x -H ldap://127.0.0.1 -w "password" -D "cn=MyApplication,dc=Contacts,dc=MyTree" "dc=Contacts,dc=MyTree" ---------- Expected behavior: ---------- ldap_delete: No such object (32) ---------- Actual behavior: ---------- Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00005566507b96e0 in mdb_delete (op=0x7f3f0c002910, rs=0x7f3f19bfd8a0) at ../../../../openldap-epel-2.6.8/openldap-2.6.8/servers/slapd/back-mdb/delete.c:151 ---------- Sample slapd.conf: ---------- include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/openldap.schema allow bind_v2 pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args modulepath /usr/lib64/openldap #moduleload back_shell.la moduleload sssvlv.la moduleload valsort.la TLSCACertificatePath /etc/openldap/certs TLSCertificateFile /etc/<path removed>.crt TLSCertificateKeyFile /etc/<path removed>.key database mdb suffix "dc=Contacts,dc=MyTree" directory "/var/lib/ldap" checkpoint 1024 1 dbnosync maxsize 1048576000 index objectClass eq,pres index ou,cn eq,pres,sub index uidNumber,gidNumber eq,pres index uid eq,pres,sub rootdn "cn=MyApplication,dc=Contacts,dc=MyTree" rootpw "{SSHA}<removed>" access to * by dn="cn=Phone,dc=Contacts,dc=MyTree" read by peername.ip=127.0.0.1 write by anonymous auth by * none overlay sssvlv sssvlv-max 1000 sssvlv-maxperconn 1000 ---------- Sample fix: I am not versed in OpenLDAP code so I can't tell if it's semantically correct. Seems like "e" gets NULL in this piece of code and the piece of code does not verify if "e" is NULL. Adding check for ( e ) makes slapd correctly return ldap_delete: No such object (32) instead of segfaulting. ---------- --- a/servers/slapd/back-mdb/delete.c 2024-05-21 19:19:11.000000000 +0200 +++ b/servers/slapd/back-mdb/delete.c 2025-05-12 14:43:04.652396852 +0200 @@ -148,17 +148,19 @@ "<=- " LDAP_XSTRING(mdb_delete) ": no such object %s\n", op->o_req_dn.bv_val ); - rs->sr_matched = ch_strdup( e->e_dn ); - if ( is_entry_referral( e )) { - BerVarray ref = get_entry_referrals( op, e ); - rs->sr_ref = referral_rewrite( ref, &e->e_name, - &op->o_req_dn, LDAP_SCOPE_DEFAULT ); - ber_bvarray_free( ref ); - } else { - rs->sr_ref = NULL; + if ( e ) { + rs->sr_matched = ch_strdup( e->e_dn ); + if ( is_entry_referral( e )) { + BerVarray ref = get_entry_referrals( op, e ); + rs->sr_ref = referral_rewrite( ref, &e->e_name, + &op->o_req_dn, LDAP_SCOPE_DEFAULT ); + ber_bvarray_free( ref ); + } else { + rs->sr_ref = NULL; + } + mdb_entry_return( op, e ); + e = NULL; } - mdb_entry_return( op, e ); - e = NULL; rs->sr_err = LDAP_REFERRAL; rs->sr_flags = REP_MATCHED_MUSTBEFREED | REP_REF_MUSTBEFREED; -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10297] New: LDAP initialization does unnecessary resolution of hostname
by openldap-its＠openldap.org 14 May '25

14 May '25

https://bugs.openldap.org/show_bug.cgi?id=10297 Issue ID: 10297 Summary: LDAP initialization does unnecessary resolution of hostname Product: OpenLDAP Version: 2.6.8 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: simon.pichugin(a)gmail.com Target Milestone: --- curl --version does try to resolve local hostname, which is usually stored in $HOSTNAME variable. It seems it does that for no good reason. It does not matter whether machine hostname is already FQDN or not, it always try it unconditionally by calling getaddrinfo(3). Every usage of dnf tries to resolve hostname. That is then supressed by myhostname on Fedora, which returns non-helping response. Possibly, the hostname should be fetched from actual network responses. Seen with: openldap-2.6.8-5.fc41.x86_64 Reproducible: Always Steps to Reproduce: 1. dnf install gdb curl 2. gdb --args curl --version 3. (gdb) break getaddrinfo 4. (gdb) run Actual Results: getaddrinfo is called with current hostname, stored into ldap_int_hostname variable. That is used only when ldap client has not configured target server. But this hostname seems fetched always. Expected Results: No network activity happens, unless something is actually requested. This is not the case. Suggestion is to make it lazy initialized. It should be tried only when necessary. This seems to be useful when tlso_session_chkhost in libraries/libldap/tls_o.c is used. It should initialize hostname only once conditions to use it happens. There is a fallback anyway. It should query FQDN only when name_in contains unusable response. Related: https://github.com/systemd/systemd/issues/34897 -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10337] New: Global TLS options not inherited in context
by openldap-its＠openldap.org 14 May '25

14 May '25

https://bugs.openldap.org/show_bug.cgi?id=10337 Issue ID: 10337 Summary: Global TLS options not inherited in context Product: OpenLDAP Version: 2.6.9 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: remi(a)fedoraproject.org Target Milestone: --- During ldap_create, global options are copied See https://github.com/openldap/openldap/blob/OPENLDAP_REL_ENG_2_6_9/libraries/… /* copy the global options */ AC_MEMCPY(&ld->ld_options, gopts, sizeof(ld->ld_options)); But not the TLS string options See https://github.com/openldap/openldap/blob/OPENLDAP_REL_ENG_2_6_9/libraries/… /* We explicitly inherit the SSL_CTX, don't need the names/paths. Leave * them empty to allow new SSL_CTX's to be created from scratch. */ memset( &ld->ld_options.ldo_tls_info, 0, sizeof( ld->ld_options.ldo_tls_info )); ld->ld_options.ldo_tls_ctx = NULL; Which create inconsistency when trying to generate a newctx For the context See * https://github.com/php/php-src/issues/17776 => why tls_newctx is needed * https://github.com/php/php-src/issues/18529 => regression On PHP side a possible workaround is to do the copyu manually * https://github.com/php/php-src/pull/18547 But should probably be handled at openldap library -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10329] New: Additional issues with pcache, and a test
by openldap-its＠openldap.org 13 May '25

13 May '25

https://bugs.openldap.org/show_bug.cgi?id=10329 Issue ID: 10329 Summary: Additional issues with pcache, and a test Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: aweits(a)rit.edu Target Milestone: --- Created attachment 1062 --> https://bugs.openldap.org/attachment.cgi?id=1062&action=edit test & patches Hello again! Further testing revealed some more issues in pcache [re: ITS#10270]. I've attached an update to test020-proxycache as well. These are based off the current git HEAD. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10333] New: Recurring crash in lmdb:mdb_page_alloc()
by openldap-its＠openldap.org 13 May '25

13 May '25

https://bugs.openldap.org/show_bug.cgi?id=10333 Issue ID: 10333 Summary: Recurring crash in lmdb:mdb_page_alloc() Product: LMDB Version: 0.9.29 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: captgol2000(a)yahoo.com Target Milestone: --- Full_Name: Version: 0.9.29 OS: Vendor built Linux based on Ubuntu kernel 4.14.173 mdb_page_alloc (SIGBUS) Number of Events: 610 We have seen a recurring crash in lmdb:mdb_page_alloc() but only in the field with our product. One instance yielded a core in which we confirmed the same stack back trace when examined. It matches the automated backtrace reports we received from field deployments. The lmdb is built from source at version 0.9.29, unchanged from upstream. The operating environment is an embedded Linux appliance with Linux kernel at version "linux-4.14.173-aum-01" and our own application that uses lmdb to store certain data while transactions are in progress. We build everything with gcc 7.3.0 and link with glibc version 2.27. Unfortunately no in-house reproduction has been possible, only a number of matching stack traces from field reports of application crashes. We are working on some system tests to see if can can cause a reproduction. This report is in hopes some others may have seen a similar backtrace to help locate a bug. (gdb) where #0 mdb_page_alloc (num=num@entry=1, mp=mp@entry=0x7ffec216d120, mc=<optimized out>) at mdb.c:2310 #1 0x00007fa2508c764e in mdb_page_new (mc=mc@entry=0x7ffec216d670, flags=flags@entry=1, num=num@entry=1, mp=mp@entry=0x7ffec216d1d0) at mdb.c:7193 #2 0x00007fa2508c7a9b in mdb_page_split (mc=mc@entry=0x7ffec216d670, newkey=newkey@entry=0x7ffec216da70, newdata=newdata@entry=0x7ffec216da50, newpgno=newpgno@entry=18446744073709551615, nflags=0) at mdb.c:8649 #3 0x00007fa2508ca4ee in mdb_cursor_put (mc=0x7ffec216d670, key=0x7ffec216da70, data=0x7ffec216da50, flags=<optimized out>) at mdb.c:6957 #4 0x00007fa2508cc26a in mdb_put (txn=0xb767020, dbi=3, key=0x7ffec216da70, data=0x7ffec216da50, flags=0) at mdb.c:9045 #5 0x00007fa2520a69f4 in XXX_XXX_store::add (this=0x7fa25230ada0 <XXX_x509_validation_s::kv_store_h>, key=0x7ffec216dbc0 "\351\066\030\201\261\223\025\\q\006\204g:\274\241\330\377Ã ", keylen=20, value=0x7ffec216db20 "\002", valuelen=19, flag=<optimized out>, table=XXX_KV_STORE_TABLE_MAIN) at lib/XXX_kv_store.cpp:479 #6 0x00007fa2520a03fa in ?? () #7 0x00007ffec216dc60 in ?? () #8 0x00007ffec216dca8 in ?? () #9 0x00007ffec216dc60 in ?? () #10 0x00007fa2520a2990 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[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 13 May '25

13 May '25

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 2

[Issue 10332] New: Add support for SSLKEYLOGFILE environment variable to export keys for Wireshark decryption
by openldap-its＠openldap.org 13 May '25

13 May '25

https://bugs.openldap.org/show_bug.cgi?id=10332 Issue ID: 10332 Summary: Add support for SSLKEYLOGFILE environment variable to export keys for Wireshark decryption Product: OpenLDAP Version: 2.6.9 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: michael.osipov(a)siemens.com Target Milestone: --- Please add support to do the following: SSLKEYLOGFILE=keylog.txt ldapsearch -H ldaps://... Other libraries and tools support it to decrypt the TLS traffic with Wireshark for analysis purposes. Curl has a simple, but complete implementation: https://github.com/curl/curl/blob/e008f71f435a39875d86885a96b2eb8968a60fd4/… Maybe it can be reused if license allows that?! -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 7901] slapschema reports error but returns 0
by openldap-its＠openldap.org 13 May '25

13 May '25

https://bugs.openldap.org/show_bug.cgi?id=7901 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |2.6.11 Keywords|needs_review | -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10335] New: [PATCH] ldapsearch: fix handling of -LL in print_reference()
by openldap-its＠openldap.org 13 May '25

13 May '25

https://bugs.openldap.org/show_bug.cgi?id=10335 Issue ID: 10335 Summary: [PATCH] ldapsearch: fix handling of -LL in print_reference() Product: OpenLDAP Version: 2.6.9 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: bolek(a)live.com Target Milestone: --- Created attachment 1066 --> https://bugs.openldap.org/attachment.cgi?id=1066&action=edit [PATCH] ldapsearch: fix handling of -LL in print_reference() I, Boleslaw Ciesielski, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. The attached patch (against master) fixes a bug in ldapsearch where the -LL (or -LLL) option is ignored when printing the reference comments in print_reference(). -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 10334] New: When there is no entry in ldap db getting success response instead of noSuchObject
by openldap-its＠openldap.org 13 May '25

13 May '25

https://bugs.openldap.org/show_bug.cgi?id=10334 Issue ID: 10334 Summary: When there is no entry in ldap db getting success response instead of noSuchObject Product: OpenLDAP Version: unspecified Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: niranjan.ganjikunta(a)ericsson.com Target Milestone: --- Created attachment 1065 --> https://bugs.openldap.org/attachment.cgi?id=1065&action=edit noSuchobject overlay module Hi Team, We are hosting an LDAP server on an Ubuntu Linux system, and our requirement is to return a noSuchObject error in the LDAP response when a search yields no results, instead of returning a success response. we are using below search command. ldapsearch -b "ou=Subscribers,ou=sda,o=centertel.pl" -D "cn=admin" -w "XXXXX" -H ldap://ip:389 -v -s sub "ptkSubscriberIMSI=26003123456789" This command is trying to search for the imsi under the base dn by using the filter. in this case if there is no entry present in db we are expecting noSuchObject (32) response from ldap. We tried to build overlay by using below c++ script to modify the default ldap behaviour to get nosuchobject when there is no entry in db. #include "portable.h" // Required for OpenLDAP build environment #include <stdio.h> #include <ac/string.h> // OpenLDAP-specific replacements #include <ac/regex.h> // Brings in regex_t, regmatch_t #include <ldap.h> #include "slap.h" #include <stdio.h> #include <ldap.h> #include <slap.h> int my_overlay_search(Operation *op, SlapReply *rs) { // Correct call to next overlay/backend int rc = overlay_op_walk(op, rs, SLAP_OP_SEARCH, (slap_overinfo *)op->o_bd->bd_info, NULL); if (rs->sr_err == LDAP_SUCCESS && rs->sr_entry == NULL) { rs->sr_err = LDAP_NO_SUCH_OBJECT; rs->sr_text = "No such object found"; Debug(LDAP_DEBUG_ANY, "Custom overlay: noSuchObject error triggered\n"); } return rc; } and by using below command build .so file gcc -fPIC -shared \ -I "$OPENLDAP_SRC/include" \ -I "$OPENLDAP_SRC/servers/slapd" \ -I "$OPENLDAP_SRC/libraries/libldap" \ -I "$OPENLDAP_SRC/libraries/liblber" \ -o "my_overlay.c" "noSuchobject_overlay.so" \ -lldap we didnt get any error while building the .so file. but while loading the module by using below ldif file content getting error dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: /usr/lib/ldap/noSuchobject_overlay.so config="/etc/ldap/ldap.conf" root@lodsto-essvt:~# ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f new_load_overlay.ldif modifying entry "cn=module{0},cn=config" ldap_modify: Other (e.g., implementation specific) error (80) additional info: <olcModuleLoad> handler exited with 1 and we got stuck in this module load. May be can you review and propose proper steps and script to build the required module to get expected ldap behaviour. Thanks in advance. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

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