https://bugs.openldap.org/show_bug.cgi?id=10488
Issue ID: 10488 Summary: Multiple out-of-bounds reads in servers/slapd/result.c v2ref() function Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs@openldap.org Reporter: wangxiaomeng@kylinos.cn Target Milestone: ---
Created attachment 1142 --> https://bugs.openldap.org/attachment.cgi?id=1142&action=edit Fix two out-of-bounds reads in servers/slapd/result.c v2ref() function
The v2ref() function in servers/slapd/result.c is responsible for converting LDAPv3 referrals to an LDAPv2-compatible string format. Two separate out-of-bounds read vulnerabilities exist in this function, both caused by insufficient checks for zero-length data before accessing the last character of the data buffer. Vulnerability 1: Out-of-bounds read in text buffer handling Location: servers/slapd/result.c, line 94 (within the v2ref() function): Vulnerable Code: if ( text != NULL ) { len = strlen( text ); if (text[len-1] != '\n') { i = 1; } }
When the 'text' parameter is non-NULL but points to an empty string (""), strlen(text) returns 0. Accessing text[len-1] (i.e., text[-1]) results in an out-of-bounds read of one byte before the start of the 'text' buffer.
Vulnerability 2: Out-of-bounds read in BerValue referral handling Location: servers/slapd/result.c, line 115 (within the v2ref() function) Vulnerable Code: len += ref[i].bv_len; if (ref[i].bv_val[ref[i].bv_len-1] != '/') { ++len; }
When ref[i].bv_val is non-NULL but ref[i].bv_len is 0 (a valid state per LDAP BerValue semantics, representing an empty string), accessing ref[i].bv_val[ref[i].bv_len-1] (i.e., ref[i].bv_val[-1]) results in an out-of-bounds read of one byte before the start of the ref[i].bv_val buffer.
Fix Add checks for zero-length data before accessing the last character of the respective buffers. The fix addresses both vulnerabilities with minimal, targeted changes that preserve the original functionality.
https://bugs.openldap.org/show_bug.cgi?id=10488
--- Comment #1 from wangxiaomeng wangxiaomeng@kylinos.cn --- Impact Both vulnerabilities can be triggered by crafted LDAPv2 requests or legitimate operations that result in empty 'text' messages or empty referral entries. Under certain memory layouts, these out-of-bounds reads may cause the slapd service to crash (segmentation fault). Additionally, they could potentially lead to information disclosure of sensitive memory contents, depending on the system's memory layout.
Intellectual Property Statement 麒麟软件有限公司 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. Signed-off-by: wangxiaomeng wangxiaomeng@kylinos.cn
https://bugs.openldap.org/show_bug.cgi?id=10488
--- Comment #2 from Howard Chu hyc@openldap.org --- (In reply to wangxiaomeng from comment #1)
Impact Both vulnerabilities can be triggered by crafted LDAPv2 requests or legitimate operations that result in empty 'text' messages or empty referral entries. Under certain memory layouts, these out-of-bounds reads may cause the slapd service to crash (segmentation fault). Additionally, they could potentially lead to information disclosure of sensitive memory contents, depending on the system's memory layout.
Intellectual Property Statement 麒麟软件有限公司 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. Signed-off-by: wangxiaomeng wangxiaomeng@kylinos.cn
LDAPv2 requests have been disallowed since 2001, commit f021404b41fd89369127f5fb654c6999fa3d7e08
There is zero operational impact from any of this.
https://bugs.openldap.org/show_bug.cgi?id=10488
--- Comment #3 from Howard Chu hyc@openldap.org --- Please provide sample requests that trigger these two conditions.
https://bugs.openldap.org/show_bug.cgi?id=10488
--- Comment #4 from wangxiaomeng wangxiaomeng@kylinos.cn --- (In reply to Howard Chu from comment #3)
Please provide sample requests that trigger these two conditions.
Thank you for the context on commit f021404b. You are right that the call site in slap_send_ldap_result is guarded by op->o_protocol < LDAP_VERSION3, and with disallow bind_v2 being the default since 2001, this path is not reachable from a network client in a default configuration.
I do not currently have a sample request that can trigger these two conditions against an unmodified slapd. The report originated from a static analysis run against result.c, not from a live exploit.
I would like to ask whether you would still consider the patch on code-hygiene grounds: 1. The two checks are one-line defensive guards with no runtime cost on the normal path; 2. They remove a class of static-analyzer warnings that downstream distributors (including us) have to carry as local patches or suppress.
If you do not consider this worth changing, I am fine with the bug being closed as WONTFIX. I just wanted to raise the option.
Thanks again for the quick review.
https://bugs.openldap.org/show_bug.cgi?id=10488
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@openldap.org |ondra@mistotebe.net Target Milestone|--- |2.7.1 Keywords|needs_review |
https://bugs.openldap.org/show_bug.cgi?id=10488
Ondřej Kuzník ondra@mistotebe.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |IN_PROGRESS
--- Comment #5 from Ondřej Kuzník ondra@mistotebe.net --- https://git.openldap.org/openldap/openldap/-/merge_requests/871
https://bugs.openldap.org/show_bug.cgi?id=10488
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Status|IN_PROGRESS |RESOLVED Target Milestone|2.7.1 |2.7.0
--- Comment #6 from Quanah Gibson-Mount quanah@openldap.org --- head:
• c27f8489 by Ondřej Kuzník at 2026-04-29T16:49:32+00:00 ITS#10488 Avoid out-of-bounds reads
https://bugs.openldap.org/show_bug.cgi?id=10488
--- Comment #7 from wangxiaomeng wangxiaomeng@kylinos.cn --- (In reply to Quanah Gibson-Mount from comment #6)
head:
• c27f8489 by Ondřej Kuzník at 2026-04-29T16:49:32+00:00 ITS#10488 Avoid out-of-bounds reads
I originally reported ITS#10488 and submitted the complete fix patch on 2026-04-09 with full issue analysis and defensive boundary checks, and added my Signed-off-by signature.
Commit c27f8489 is revised and adjusted based entirely on my original patch solution, the core fix logic, zero-length judgment logic and problem-solving ideas come from my original submission.
I fully respect the subsequent code style adjustments and detail optimizations made by Ondřej Kuzník, but hope to retain the original contribution attribution and my Signed-off-by information in the commit record, to correctly record the original discoverer and core fix author of this issue.
Thanks for the community work and proper contribution attribution. Signed-off-by: wangxiaomeng wangxiaomeng@kylinos.cn
https://bugs.openldap.org/show_bug.cgi?id=10488
--- Comment #8 from Howard Chu hyc@openldap.org --- (In reply to wangxiaomeng from comment #7)
(In reply to Quanah Gibson-Mount from comment #6)
head:
• c27f8489 by Ondřej Kuzník at 2026-04-29T16:49:32+00:00 ITS#10488 Avoid out-of-bounds reads
I originally reported ITS#10488 and submitted the complete fix patch on 2026-04-09 with full issue analysis and defensive boundary checks, and added my Signed-off-by signature.
With respect, your submission was a non-issue, and you confirmed that there was no path from which a client could trigger it. The only reason we committed a change was to avoid redundant reports from automated tools in the future, not because there was anything that actually needed fixing.
Commit c27f8489 is revised and adjusted based entirely on my original patch solution, the core fix logic, zero-length judgment logic and problem-solving ideas come from my original submission.
I fully respect the subsequent code style adjustments and detail optimizations made by Ondřej Kuzník, but hope to retain the original contribution attribution and my Signed-off-by information in the commit record, to correctly record the original discoverer and core fix author of this issue.
Thanks for the community work and proper contribution attribution. Signed-off-by: wangxiaomeng wangxiaomeng@kylinos.cn
The extent of your contribution remains fully documented here in the ITS.