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

[email protected] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|VERIFIED                    |UNCONFIRMED
         Resolution|FEEDBACK                    |---

--- Comment #2 from [email protected] ---
Hi,

Apologies for the delayed response.
To replicate the scenario, We deployed this openldap libraries on two different
servers and performed the testing.
Issue was reproduced in one application deployed on a physical server, whereas
it is not reproduced in application deployed on another virtual machine.
After debugging the code, we found out that the bind dn is getting corrupted in
the following code.

unsigned char *p = ber_prepend_len( lenptr + SOS_LENLEN, len );
ber_len_t unused = p - lenptr;
if ( unused != 0 ) {
        /* length(length) < the reserved SOS_LENLEN bytes */
        xlen -= unused;
        AC_MEMCPY( lenptr, p, xlen );
        ber->ber_sos_ptr = (char *) lenptr + xlen;
}

This code is present inside the ber_put_seqorset function which is a part of
encode.c file.
This ber_put_seqorset function is getting called from ber_printf function which
will insert bind dn string into ber element.

In the above code, bind dn is getting malformed in AC_MEMCPY macro call.
BEFORE AC_MEMCPY macro call: lenptr + SOS_LENLEN = ^B^A^C^D uid=abc, ou=users,
dc=fds, dc=mr~@^Fpasskey
AFTER AC_MEMCPY macro call: lenptr + SOS_LENLEN = uid=abc,users, ds, dc= dc=
dc=mr~@^Fpasskeyskey

As per the doucmentation, AC_MEMCPY will do the safe copy of memory blocks.
By default it is calling the memcpy function inside AC_MEMCPY macro(depends on
the compile time flags HAVE_MEMMOVE,HAVE_BCOPY).
We replaced AC_MEMCPY with memmove and the issue was resolved and the bind dn
is parsed as expected.

memmove will check for overlapping memory locations, whereas memcpy doesn't.

So, Can we replace this AC_MEMCPY with memmove? Or, Can we enable the
HAVE_MEMMOVE during compilation?
If yes, can you please provide some inputs on the impact of this code change.
Is there any other specific reason behind this abrupt behavior in one server.
If yes, Kindly let us know so that we will address that one instead of making
the code change in the above function.

Thanks,
Satish S

-- 
You are receiving this mail because:
You are on the CC list for the issue.

Reply via email to