https://bugs.openldap.org/show_bug.cgi?id=10489
--- Comment #14 from yutengsun1997@gmail.com --- Thank you for the clarification and for taking the time to explain the rationale.
You mentioned there is no known third-party application using liblber directly that is affected, which challenged me to verify this. I found a concrete counterexample: FreeIPA, a widely deployed enterprise identity management system.
In daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_worker.c, FreeIPA uses ber_init2() strictly to parse unauthenticated Connectionless LDAP (CLDAP) UDP packets, passing the buffer exactly as received from the network, with no extra +1 byte allocated: ```C // ipa_cldap.h struct ipa_cldap_req { char dgram[MAX_DG_SIZE]; // MAX_DG_SIZE = 4096, fixed-size network buffer size_t dgsize; // bytes actually received // ... };
// ipa_cldap_worker.c bv.bv_val = req->dgram; // exact-size buffer, NO +1 bv.bv_len = req->dgsize; ber_init2(be, &bv, 0); // ... ber_skip_tag(be, &len);
```
I wrote a small PoC mimicking this exact memory logic to prove it. If an attacker sends a simply crafted datagram (e.g., a 2-byte empty sequence 0x30 0x00), recvfrom sets dgsize = 2. The ber_skip_tag() function unconditionally dereferences ber_ptr, reading dgram[2], which is 1 byte out of bounds of the logically provided bv_len.
To be completely objective: in this specific FreeIPA build, this OOB read will not trigger a Segfault or an ASan crash. This is strictly due to "bug masking by memory layout" — because dgram is a static array enclosed within the calloc'd struct and is immediately followed by dgsize, the OOB read quietly fetches the first byte of dgsize. However, this definitively proves that the vulnerable pattern exists. If FreeIPA or any other application had chosen the standard idiom of using char *dgram = malloc(dgsize);, this would be an instantly exploitable Heap-Buffer-Overflow against a network-facing daemon.
I would also like to add two minor points for your consideration: 1. Closed-source Prevalence: While it might be uncommon to find direct liblber usage in open-source clients, LDAP is overwhelmingly used in proprietary enterprise directory solutions, legacy identity management gateways, and customized network appliances. These closed-source applications may very well be using ber_init2 dynamically, completely unaware of the undocumented +1 sentinel requirement. 2. My Background & Request: To be transparent, I am not primarily doing manual source auditing. I found this issue systematically while building infrastructure to measure and fuzz DER/BER parsers at scale. On a personal level, having a CVE assigned would be beneficial for my academic/research work. However, I want to be respectful of your time and your project's security policies. If you strongly feel this does not cross the threshold for a CVE from the OpenLDAP project's perspective, I will gladly respect that decision and will simply note it as "Reported to vendor; <fixed>" (<> means it might not appear) in my research evaluation.
I will leave the final assessment in your hands. Thank you again for the fantastic work on OpenLDAP and for reviewing my findings!