https://bugs.openldap.org/show_bug.cgi?id=10147
satishkumar1728@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|VERIFIED |UNCONFIRMED Resolution|FEEDBACK |---
--- Comment #2 from satishkumar1728@gmail.com --- 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