openldap-devel February 2026

openldap-devel@openldap.org

4 participants
5 discussions

Modifying the modification
by Emmanuel Dreyfus 13 Feb '26

13 Feb '26

Hello In an overlay, I want to alter a modification operation so that modification to an attribute is not done. I crafted the code below, which seems to work, but is it right? There are XXX places where I expected another behavior, did I miss something? And after "Modifying the modification", I also have "Modifying an add", just below, with the same questions. /* Modifying the modification */ static void supann_rm_mods(Modifications *mods, Modifications **mods_prevp) { Modifications *mods_next = mods->sml_next; int freeit = 0; /* XXX Setting freeit to 1 crashes */ slap_mod_free(&mods->sml_mod, freeit); mods->sml_numvals = 0; free(mods); *mods_prevp = mods_next; return; } And this how it is used (of course removeit is a more complex logic, it is removed here for the sake of clarity) Modifications *mods; Modifications **mods_prev; Modifications *mods_next; mods_prev = &op->orm_modlist; for (mods = op->orm_modlist; mods; mods = mods_next) { short sm_op = mods->sml_op; Attribute a; mods_next = mods->sml_next; if (remove_it) supann_rm_mods(mods, mods_prev); else mods_prev = &mods->sml_next; } Same question, for add oprations: /* Modifying the add */ static void supann_rm_attr(Attribute *a, Attribute **a_prevp) { Attribute *a_next = a->a_next; attr_clean(a); #if 0 /* XXX This crashes */ free(a); #endif *a_prevp = a_next; return; } And its usage: Attribute **a_prev; Attribute *a_next; a_prev = &op->ora_e->e_attrs; for (a = op->ora_e->e_attrs; a; a = a_next) { a_next = a->a_next; if (removeit) supann_rm_attr(a, a_prev); else a_prev = &a->a_next; } -- Emmanuel Dreyfus manu(a)netbsd.org

2 4

[RESEND] Proposal: Continuous fuzzing support via OSS-Fuzz
by emptyiscolor＠gmail.com 12 Feb '26

12 Feb '26

Dear OpenLDAP team, Apologies if this is a duplicate — I’m resending this message in case my previous post did not reach the list. I’m writing to ask for guidance on potential ongoing fuzzing and security contributions for OpenLDAP. This is not a bug report or patch submission. Brief context: we recently reported Bug 10429, which was fixed in MR 826 (thank you). We have since been applying our fuzzing infrastructure to OpenLDAP and integrated a set of LibFuzzer-based harnesses into OSS-Fuzz. Draft OSS-Fuzz integration: https://github.com/google/oss-fuzz/pull/14872 In addition to Bug 10429, several related issues identified through fuzzing have recently been reported to the Issue Tracking System by my collaborator Kang Yang (Issues 10445, 10446, 10447, 10448, 10449, and 10450), which further motivates broader and continuous fuzzing coverage. At present, this work lives entirely in OSS-Fuzz and does not modify the OpenLDAP source tree. We are continuing to verify additional harnesses and investigate findings; any confirmed bugs and patches will be submitted via the Issue Tracking System in accordance with the contribution guidelines. We would appreciate guidance on whether this OSS-Fuzz integration approach aligns with OpenLDAP’s expectations, and whether there are preferences regarding API scope or future in-tree fuzzing work. Thanks for your time. Best regards, Yunhang Zhang University of Utah

1 0

Request for comment: allow ACLs to trigger based on op/controls
by Ondřej Kuzník 12 Feb '26

12 Feb '26

Dear community, for the next release, I've been preparing extensions to the ACL syntax to address a feature request that comes up relatively often - restrict access to data/actions based on what controls are involved. My thinking is that we could allow the following stanzas in the "access to <what>" part: - op=<operation name> or op=<OID> for extended requests - control=<OID> In here, we would probably provide a shorthand for known OIDs using the OID macro in schemas, so you could write something like this: ---- 8< ---- access to dn.subtree=ou=people,dc=example,dc=com attrs=userPassword control=ppolicy by anonymous auth access to dn.subtree=ou=people,dc=example,dc=com attrs=userPassword by group=cn=admin,ou=groups,dc=example,dc=com write by * none ---- 8< ---- As this is a deep change in how people work with ACLs, I'd like some feedback from the community at large before we commit to changing the syntax in a way that we have to live with for a long time. Have you needed something like this? Does the proposed addition solve your use-case? Can you see issues that are not covered or new ones that could crop up when used like this and might not be desirable? Any other feedback or proposals for how this could be expressed are also welcome. I'd like to add that this is unlikely to land until consensus has been achieved in the first place. For those happy to test actual code, the above proposal lives in a merge request: https://git.openldap.org/openldap/openldap/-/merge_requests/720 Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Proposal: Continuous fuzzing support via OSS-Fuzz
by emptyiscolor＠gmail.com 09 Feb '26

09 Feb '26

Dear OpenLDAP team, My name is Yunhang Zhang, working with Prof. Jun Xu at the University of Utah (CS). We recently reported a NULL pointer dereference issue to OpenLDAP (Bug 10429), which was fixed in merge request [826](https://git.openldap.org/openldap/openldap/-/merge_requests/826) . Thank you for the prompt fix. I’m writing to discuss potential ongoing fuzzing and security contributions and to ask for guidance on the preferred process. We are part of the DARPA AI Cyber Challenge (AIxCC) finalist team “42-b3yond-6ug,” where we developed an AI-driven Cyber Reasoning System (CRS) that automatically generates fuzzing harnesses and discovers vulnerabilities in large C/C++ codebases. Applying this system to OpenLDAP so far, we have: * Generated LibFuzzer-compatible fuzzing harnesses targeting public OpenLDAP APIs * Validated the harnesses against documented interfaces * Integrated the harnesses into OSS-Fuzz for continuous testing Our draft OSS-Fuzz integration is available here: https://github.com/google/oss-fuzz/pull/14872 At present, this work lives entirely in OSS-Fuzz and does not modify the OpenLDAP source tree. We are continuing to verify additional harnesses and investigate findings; any confirmed bugs and corresponding patches will be submitted through the Issue Tracking System in accordance with the contribution guidelines. The goal is to improve long-term robustness and security coverage with minimal maintenance overhead for the OpenLDAP project. We believe broader fuzzing coverage can help detect regressions and subtle issues earlier over time. We would appreciate guidance from the community on whether this approach aligns with OpenLDAP’s expectations, and whether there are preferences regarding API scope, exclusions, or future in-tree fuzzing contributions. Thanks for your time and for maintaining OpenLDAP. Best regards, Yunhang Zhang University of Utah (on behalf of the 42-b3yond-6ug / DARPA AIxCC team)

1 0

slapd memory management revisited
by Howard Chu 09 Feb '26

09 Feb '26

Back when I first wrote sl_malloc, the idea was to grow the slab as needed and never have a free() method. Somewhere along the line this idea was shot down and we implemented free() anyway. I believe that was a mistake. If we get around to reimplementing this in 2.7 or 2.8, or 3.0... There should be these main classes of memory allocations: 1) per-server: this would mostly be config info, and any necessary per-database stuff. Can continue to use chmalloc/chfree. 2) per-connection: not much besides authc/authz. continue to use chmalloc/chfree. 3) per-operation: the BER structures for parsing an incoming request, plus any per-operation handling. This would use the equivalent of the current op->o_tmpmemctx. Would also include ACL cache, which is also relevant to an entire operation. 4) per-message: Only Search requests have multiple response messages. This would primarily be the structures needed to construct a search response. This would be a newly defined slab, which is reset before sending any search response. 5) per-function: Sometimes needed to allocate arrays used to return values from e.g. a normalization function. This would be a newly defined slab. We might continue to avoid the need for this, with the same trick we already use in libldap: do a pre-parse pass where we count the sizes of the values and arrays we need to return, and only allocate them after all sizes are known. The idea is that in routine operation, there is no need to call any kind of free() function. Just an occasional reset() on some slabs before they get reused. In practice, free() is more expensive than malloc() because it may have to walk many memory blocks to try to coalesce them, so it's of great benefit to eliminate any need for a free() function. As for growing the sl_malloc slab dynamically - this would be done without realloc. Instead just use a linked list of slab chunks, and allocate memory from the tail chunk. On slab reset, free all the chunks except for the initial one. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel February 2026