https://bugs.openldap.org/show_bug.cgi?id=10489

--- Comment #2 from yutengsun1997@gmail.com --- Actually, I did not receive anything. I reported it to project@openldap.org. Is this the right place to report it? If not, could you please give me an email address? Alternatively, can I download and attach the original email here?

https://bugs.openldap.org/show_bug.cgi?id=10489

--- Comment #4 from yutengsun1997@gmail.com --- Got it, here is the origial email content.

Subject: Possible memory issue in liblber: ber_skip_tag() / ber_skip_element() / ber_skip_data() — unchecked ber_ptr dereference

Dear OpenLDAP Security Team,

I hope this message finds you well. I have been doing some security research on BER/DER parsing libraries and came across a potential memory issue in liblber that I would appreciate your assessment on.

## Summary

Three functions in liblber dereference `ber->ber_ptr` to cache the next tag byte without verifying that `ber_ptr < ber_end`. When the current element is the last one in the buffer (or when parsing fails), `ber_ptr` may point at or past `ber_end`, resulting in a 1-byte out-of-bounds read.

I wanted to ask: would you consider this a memory safety issue worth addressing?

## Affected Code

**OpenLDAP 2.6.9** (and likely all prior versions). Three locations:

### 1. `ber_skip_tag()` — libraries/liblber/decode.c:274-275

```c ber->ber_ptr = bv.bv_val; ber->ber_tag = *(unsigned char *) ber->ber_ptr; // unconditional dereference ```

This runs regardless of whether `ber_peek_element()` succeeded or failed. Unlike `ber_skip_element()`, there is no `if (tag != LBER_DEFAULT)` guard, so the dereference occurs even on parse failure.

### 2. `ber_skip_element()` — libraries/liblber/decode.c:230-231

```c ber->ber_ptr = bv.bv_val + bv.bv_len; ber->ber_tag = *(unsigned char *) ber->ber_ptr; // OOB when last element ```

When the parsed element is the last one in the buffer, `ber_ptr` is advanced to exactly `ber_end`, and the read goes 1 byte past the buffer.

### 3. `ber_skip_data()` — libraries/liblber/io.c:62-63

```c ber->ber_ptr += actuallen; ber->ber_tag = *(unsigned char *)ber->ber_ptr; // same pattern ```

## Why ber_init() masks the issue

I noticed that `ber_init()` allocates `bv_len + 1` bytes and NUL-terminates the copy, so the out-of-bounds read hits a sentinel byte within the allocation. This effectively masks the issue in many common code paths.

However, `ber_init2()` uses the caller's buffer in-place without extra allocation, which makes the out-of-bounds read a real access past the buffer boundary.

## Reachability via ber_init2()

From what I can see, `ber_init2()` is called in a number of places that process incoming data, including:

- `servers/slapd/cancel.c` — extended operation request data - `servers/slapd/passwd.c` — password modify request data - `servers/slapd/controls.c` — LDAP control values - `servers/slapd/schema_init.c` — DER-encoded attribute values - `servers/lloadd/bind.c`, `servers/lloadd/client.c` — load balancer data - `libraries/libldap/result.c` — client-side server response parsing - `libraries/libldap/tls_g.c:504` — X.509 certificate DN extraction - Various overlays (syncprov, sssvlv, deref, valsort, etc.)

## Reproduction

A minimal example using `ber_init2()`, compiled with AddressSanitizer:

```c #include <lber.h> #include <stdint.h>

int main(void) { // A complete NULL element: tag=0x05, length=0x00 uint8_t buf[2] = {0x05, 0x00};

BerElement *ber = ber_alloc_t(0); struct berval bv; bv.bv_val = (char *)buf; bv.bv_len = sizeof(buf); ber_init2(ber, &bv, 0);

// ber_skip_tag() advances ber_ptr to buf[2] (past end), // then dereferences it to cache ber_tag. ber_len_t len = 0; ber_skip_tag(ber, &len);

ber_free(ber, 0); return 0; } ```

Compile and run: ```bash clang -g -O1 -fsanitize=address,undefined -I<openldap>/include \ -DLBER_LIBRARY decode.c io.c memory.c options.c sockbuf.c \ bprint.c debug.c assert.c encode.c stdio.c test.c -o test ./test ```

ASan reports: ``` ERROR: AddressSanitizer: stack-buffer-overflow on address ... READ of size 1 at ... #0 ... in ber_skip_tag .../decode.c:275 ```

## Suggested Fix

A bounds check before each `ber_ptr` dereference would address this:

```c if (ber->ber_ptr < ber->ber_end) ber->ber_tag = *(unsigned char *) ber->ber_ptr; else ber->ber_tag = LBER_DEFAULT; ```

Additionally, `ber_skip_tag()` could benefit from the same `if (tag != LBER_DEFAULT)` guard that `ber_skip_element()` already has, to avoid the dereference on parse failure.

## Notes

- I understand that `ber_init()` mitigates this in practice for many code paths. I am reporting this primarily because `ber_init2()` is a public API and is used internally in places that handle incoming data. - I have only tested this on OpenLDAP 2.6.9 but the code pattern appears to have been present for a long time.

Thank you very much for your time and for maintaining OpenLDAP. I would be happy to provide any additional information or testing if that would be helpful.

Best regards.

https://bugs.openldap.org/show_bug.cgi?id=10489

Howard Chu hyc@openldap.org changed:

What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Target Milestone|--- |2.6.14 Status|UNCONFIRMED |RESOLVED Keywords|needs_review |

https://bugs.openldap.org/show_bug.cgi?id=10489

--- Comment #7 from yutengsun1997@gmail.com --- Thanks for your quick reply.

https://bugs.openldap.org/show_bug.cgi?id=10489

--- Comment #9 from Howard Chu hyc@openldap.org --- I'm quite reluctant to issue a CVE for this since there is no known instance of an application that's affected by it. It's really uncommon for 3rd party applications to use liblber directly, usually the use libldap and won't be exposed to the issue anyway. If you know of any application calling liblber directly, that is vulnerable, then we can discuss it further.

https://bugs.openldap.org/show_bug.cgi?id=10489

--- Comment #11 from yutengsun1997@gmail.com --- Hi,

I spent a lot of time to check the call graph of OpenLDAP, and found the `+1` guarantee does NOT cover all code path.

The `ber_get_next() +1` sentinel applies only to buffers from incoming LDAP messages. But `tlsg_x509_cert_dn()` in `libldap/tls_g.c:532` receives its buffer from a completely different allocator: ``` ldap_pvt_tls_get_peer_dn() ← public libldap API → tlsg_session_peer_dn() bv.bv_val = peer_cert_list->data ← gnutls_malloc(data_size) bv.bv_len = peer_cert_list->size ← exactly data_size, NO +1 tlsg_x509_cert_dn(&bv, ..., 1) ber_init2(ber, cert, LBER_USE_DER) ← uses caller's buffer directly ber_skip_tag() → *(unsigned char*)ber_ptr ← OOB when ber_ptr==ber_end

``` Proven in GnuTLS source — `_gnutls_set_datum()` at `datum.c:42`: ``` unsigned char *m = gnutls_malloc(data_size); // exactly data_size, no +1 dat->data = m; // ← no + 1 dat->size = data_size; // ← no + 1 ``` This is OpenLDAP's own code calling a third-party allocator that follows no such internal convention. The `+1` defence relies on an undocumented internal convention that is invisible to any external allocator.

Please let me know if I made any mistakes. And I'd like to see your comments. Many Thanks.

https://bugs.openldap.org/show_bug.cgi?id=10489

--- Comment #13 from Quanah Gibson-Mount quanah@openldap.org --- head:

• 14f3e733 by Howard Chu at 2026-04-09T17:41:03+01:00 ITS#10489 liblber: fix potential 1-byte overread

RE26:

• 4ad04879 by Howard Chu at 2026-04-10T22:49:08+00:00 ITS#10489 liblber: fix potential 1-byte overread

https://bugs.openldap.org/show_bug.cgi?id=10489

--- Comment #15 from Ondřej Kuzník ondra@mistotebe.net --- On Sat, Apr 11, 2026 at 09:00:51AM +0000, openldap-its@openldap.org wrote:

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.

You are saying this one byte overread is exploitable, that is quite the claim, can you explain how this capability could be "exploitable" to gain anything? In my view an application would need to be extremely reckless in the first place to allow crafting this into a widget for something like attacker controlled reads...

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.

And why I'm +1 to keep the fix in.

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!

In the beginning you mentioned this is a safety issue (bug), not a security issue (vulnerability). On that I agree, and you would have to show why it needs to be reclassified or have any of our downstreams weigh in.

We are grateful for every valid issue report and happy to discuss their potential ramifications within reason. But at this point it is up to you to show why it is serious enough to warrant a CVE, which I believe you acknowledged is contrary to how the project handles safety issues and only benefits you.

Thanks,