openldap-bugs August 2010

openldap-bugs@openldap.org

23 participants
68 discussions

Re: (ITS#6637) valgrind issues in SSL code
by hyc＠symas.com 30 Aug '10

30 Aug '10

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.23 > OS: Linux 2.6 > URL: http://www.stanford.edu/~quanah/valgrind.txt > Submission from: (NULL) (75.111.45.108) > > > Numerous > ==30949== Conditional jump or move depends on uninitialised value(s) > and > Use of uninitialised value of size 8 > > errors. See: > http://www.stanford.edu/~quanah/valgrind.txt All irrelevant. OpenSSL is intentionally written to use uninit'd bytes in its random number generators etc., and none of this is an OpenLDAP issue anyway. Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6339) ldapsearch -V doesn't exist after version info
by matheus.morais＠gmail.com 30 Aug '10

30 Aug '10

--0016364ec88477ac37048f173de5 Content-Type: text/plain; charset=ISO-8859-1 Hi there, <quote> That's... bizarre. Even slapd doesn't behave that way. Nor any other program comes immediately to mind. </quote> Even sounds like an strange behave, as Quanah said, this information should be included on ldapsearch man page IMHO. I believe that the following patch could close this BUG: --- openldap/doc/man/man1/ldapsearch.1.orig 2010-08-31 01:25:23.000000000 -0300 +++ openldap/doc/man/man1/ldapsearch.1 2010-08-31 01:37:50.000000000 -0300 @@ -7,6 +7,8 @@ .SH SYNOPSIS .B ldapsearch [\c +.BR \-V [ V ]] +[\c .BR \-n ] [\c .BR \-c ] @@ -107,6 +109,11 @@ Option \fI\-L\fP controls the format of the output. .SH OPTIONS .TP +.BR \-V [ V ] +Prints the ldapsearch version and proceeds with the search. +.B \-VV +Prints the ldapsearch version and quit. +.TP .B \-n Show what would be done, but don't actually perform the search. Useful for debugging in conjunction with \fB\-v\fP. Please review it. Thanks, Matheus Morais --0016364ec88477ac37048f173de5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi there, <quote> That's... bizarre. Even slapd doesn&#39= ;t behave that way. Nor any other program comes immediately to mind. </= quote> Even sounds like an strange behave, as Quanah said, this i= nformation should be included on ldapsearch man page IMHO. I believe that the following patch could close this BUG: --- ope= nldap/doc/man/man1/ldapsearch.1.orig=A0=A0=A0 2010-08-31 01:25:23.000000000= -0300 +++ openldap/doc/man/man1/ldapsearch.1=A0=A0=A0 2010-08-31 01:37:= 50.000000000 -0300 @@ -7,6 +7,8 @@ =A0.SH SYNOPSIS =A0.B ldapsearch =A0[\c +.BR \-= V [ V ]] +[\c =A0.BR \-n ] =A0[\c =A0.BR \-c ] @@ -107,6 +10= 9,11 @@ =A0Option \fI\-L\fP controls the format of the output. =A0.SH= OPTIONS =A0.TP +.BR \-V [ V ] +Prints the ldapsearch version and proceeds wit= h the search. +.B \-VV +Prints the ldapsearch version and quit. +.= TP =A0.B \-n =A0Show what would be done, but don't actually perfo= rm the search.=A0 Useful for =A0debugging in conjunction with \fB\-v\fP. Please review it. <br= >Thanks, Matheus Morais --0016364ec88477ac37048f173de5--

1 0

(ITS#6637) valgrind issues in SSL code
by quanah＠OpenLDAP.org 30 Aug '10

30 Aug '10

Full_Name: Quanah Gibson-Mount Version: 2.4.23 OS: Linux 2.6 URL: http://www.stanford.edu/~quanah/valgrind.txt Submission from: (NULL) (75.111.45.108) Numerous ==30949== Conditional jump or move depends on uninitialised value(s) and Use of uninitialised value of size 8 errors. See: http://www.stanford.edu/~quanah/valgrind.txt --Quanah

1 0

Re: (ITS#6633) test030-relay: Passwd ExOp failed (1)!
by michael＠stroeder.com 29 Aug '10

29 Aug '10

Seems to be fixed now.

1 0

Re: (ITS#6634) potential leak when ARG_BERVAL|ARG_OFFSET
by masarati＠aero.polimi.it 29 Aug '10

29 Aug '10

> Full_Name: Pierangelo Masarati > Version: HEAD/re24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (129.72.165.149) > Submitted by: ando > > > config_get_vals() in the above case first duplicates the berval from the > pointer; then assigns it to "bv"; finally, it calls value_add_one(), which > further duplicates the berval. When ARG_STRING, instead, after the string > is > turned into a berval, ber_bvarray_add() is called. > > As far as I could tell, this only occurs for olcDbDirectory of back-ldif. Things seem to be a little bit more complicated: - when ARG_OFFSET && ARG_STRING, copy the string, then ber_bvarray_add() - when ARG_MAGIC && ARG_STRING, ber_bvarray_add() - when ARG_OFFSET && ARG_BERVAL, don't copy the string, value_add_one() - when ARG_MAGIC && ARG_BERVAL, value_add_one() A fix is coming. p.

1 0

(ITS#6635) when an undefined attribute is used in a presence filter, the temporary description can leak
by masarati＠aero.polimi.it 29 Aug '10

29 Aug '10

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.165.149) Submitted by: ando A fix is coming. p.

1 0

(ITS#6634) potential leak when ARG_BERVAL|ARG_OFFSET
by masarati＠aero.polimi.it 29 Aug '10

29 Aug '10

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.165.149) Submitted by: ando config_get_vals() in the above case first duplicates the berval from the pointer; then assigns it to "bv"; finally, it calls value_add_one(), which further duplicates the berval. When ARG_STRING, instead, after the string is turned into a berval, ber_bvarray_add() is called. As far as I could tell, this only occurs for olcDbDirectory of back-ldif. p.

1 0

Re: (ITS#6633) test030-relay: Passwd ExOp failed (1)!
by masarati＠aero.polimi.it 29 Aug '10

29 Aug '10

*should* be fixed. Unnoticed side effect of ITS#6632 hack. Thanks, p.

1 0

(ITS#6633) test030-relay: Passwd ExOp failed (1)!
by michael＠stroeder.com 29 Aug '10

29 Aug '10

Full_Name: Michael Ströder Version: HEAD OS: Linux URL: Submission from: (NULL) (84.163.34.243) Please let me know if you need logs. $ ./run -b bdb test030 Cleaning up test run directory leftover from previous run. Running ./scripts/test030-relay for bdb... running defines.sh Testing virtual naming context mapping with relay ldap meta backend(s)... Using relay backend... Starting slapd on TCP/IP port 9011... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Searching base="dc=example,dc=com"... Searching base="o=Example,c=US"... Searching base="o=Esempio,c=IT"... Searching base="o=Beispiel,c=DE"... Modifying database "o=Beispiel,c=DE"... Modifying database "o=Example,c=US"... Searching base="o=Example,c=US"... Searching base="o=Esempio,c=IT"... Searching filter="(objectClass=referral)" attrs="'*' ref" base="dc=example,dc=com"... base="o=Example,c=US"... base="o=Esempio,c=IT"... Searching filter="(seeAlso=cn=all staff,ou=Groups,o=Example,c=US)" attrs="seeAlso" base="o=Example,c=US"... Searching filter="(uid=example)" attrs="uid" base="o=Example,c=US"... Searching filter="(member=cn=Another Added Group,ou=Groups,o=Example,c=US)" attrs="member" base="o=Example,c=US"... Filtering ldapsearch results... Filtering original ldif used to create database... Comparing filter output... Changing password to database "o=Example,c=US"... Passwd ExOp failed (1)!

1 0

Re: (ITS#6632) Core dump in test030 when using back-ldap
by masarati＠aero.polimi.it 28 Aug '10

28 Aug '10

It is clearly slapo-rwm(5), whose cleanup function is not executed early enough when dealing with extended operations, since the latter delegate successful return to the frontend: modified logging... conn=1000 op=1 EXT oid=1.3.6.1.4.1.4203.1.11.1 conn=1000 op=1 PASSMOD id="cn=Added User,ou=Alumni Association,ou=People,o=Example,c=US" new ### conn=1000 op=1: passwd_extop: setting dn="cn=Added User,ou=Alumni Association,ou=People,o=Example,c=US" (0x4972608) ### conn=1000 op=1: rwm_extended: setting dn="cn=Added User,ou=Alumni Association,ou=People,dc=example,dc=com" (0x4972ed0) conn=1001 op=1 EXT oid=1.3.6.1.4.1.4203.1.11.1 conn=1001 op=1 PASSMOD id="cn=Added User,ou=Alumni Association,ou=People,dc=example,dc=com" new ### conn=1001 op=1: passwd_extop: setting dn="cn=Added User,ou=Alumni Association,ou=People,dc=example,dc=com" (0x4975ba8) ### conn=1001 op=1: passwd_extop: freeing dn="cn=Added User,ou=Alumni Association,ou=People,dc=example,dc=com" (0x4975ba8) ### conn=1000 op=1: passwd_extop: freeing dn="cn=Added User,ou=Alumni Association,ou=People,dc=example,dc=com" (0x4972ed0) ### conn=1000 op=1: rwm_op_rollback: freeing dn="cn=Added User,ou=Alumni Association,ou=People,dc=example,dc=com" (0x4972ed0) conn=1000 op=1 RESULT oid= err=0 text= ==23914== Thread 3: ==23914== Invalid read of size 1 ==23914== at 0x4006238: strlen (mc_replace_strmem.c:246) ==23914== by 0xCB184D: vfprintf (in /lib/libc-2.5.so) ==23914== by 0xCD1FD3: vsnprintf (in /lib/libc-2.5.so) ==23914== by 0x826B0C6: lutil_debug (debug.c:66) ==23914== by 0x80C8C85: do_extended (extended.c:185) ==23914== by 0x808ACB9: connection_operation (connection.c:1109) ==23914== by 0x8234F88: ldap_int_thread_pool_wrapper (tpool.c:685) ==23914== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==23914== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==23914== Address 0x4972608 is 0 bytes inside a block of size 62 free'd ==23914== at 0x4004FDA: free (vg_replace_malloc.c:233) ==23914== by 0x826B139: ber_memfree_x (memory.c:152) ==23914== by 0x80F551F: slap_sl_free (sl_malloc.c:481) ==23914== by 0x80CA4C7: passwd_extop (passwd.c:326) ==23914== by 0x80C8F01: fe_extended (extended.c:225) ==23914== by 0x80C8C06: do_extended (extended.c:177) ==23914== by 0x808ACB9: connection_operation (connection.c:1109) ==23914== by 0x8234F88: ldap_int_thread_pool_wrapper (tpool.c:685) ==23914== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==23914== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==23914== ==23914== Invalid read of size 1 ==23914== at 0x4006243: strlen (mc_replace_strmem.c:246) ==23914== by 0xCB184D: vfprintf (in /lib/libc-2.5.so) ==23914== by 0xCD1FD3: vsnprintf (in /lib/libc-2.5.so) ==23914== by 0x826B0C6: lutil_debug (debug.c:66) ==23914== by 0x80C8C85: do_extended (extended.c:185) ==23914== by 0x808ACB9: connection_operation (connection.c:1109) ==23914== by 0x8234F88: ldap_int_thread_pool_wrapper (tpool.c:685) ==23914== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==23914== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==23914== Address 0x4972609 is 1 bytes inside a block of size 62 free'd ==23914== at 0x4004FDA: free (vg_replace_malloc.c:233) ==23914== by 0x826B139: ber_memfree_x (memory.c:152) ==23914== by 0x80F551F: slap_sl_free (sl_malloc.c:481) ==23914== by 0x80CA4C7: passwd_extop (passwd.c:326) ==23914== by 0x80C8F01: fe_extended (extended.c:225) ==23914== by 0x80C8C06: do_extended (extended.c:177) ==23914== by 0x808ACB9: connection_operation (connection.c:1109) ==23914== by 0x8234F88: ldap_int_thread_pool_wrapper (tpool.c:685) ==23914== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==23914== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==23914== ==23914== Invalid read of size 4 ==23914== at 0xCE232C: mempcpy (in /lib/libc-2.5.so) ==23914== by 0xCB1375: vfprintf (in /lib/libc-2.5.so) ==23914== by 0xCD1FD3: vsnprintf (in /lib/libc-2.5.so) ==23914== by 0x826B0C6: lutil_debug (debug.c:66) ==23914== by 0x80C8C85: do_extended (extended.c:185) ==23914== by 0x808ACB9: connection_operation (connection.c:1109) ==23914== by 0x8234F88: ldap_int_thread_pool_wrapper (tpool.c:685) ==23914== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==23914== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==23914== Address 0x4972608 is 0 bytes inside a block of size 62 free'd ==23914== at 0x4004FDA: free (vg_replace_malloc.c:233) ==23914== by 0x826B139: ber_memfree_x (memory.c:152) ==23914== by 0x80F551F: slap_sl_free (sl_malloc.c:481) ==23914== by 0x80CA4C7: passwd_extop (passwd.c:326) ==23914== by 0x80C8F01: fe_extended (extended.c:225) ==23914== by 0x80C8C06: do_extended (extended.c:177) ==23914== by 0x808ACB9: connection_operation (connection.c:1109) ==23914== by 0x8234F88: ldap_int_thread_pool_wrapper (tpool.c:685) ==23914== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==23914== by 0xD42DBD: clone (in /lib/libc-2.5.so) ### conn=1000 op=1: do_extended: freeing dn="cn=Added User,ou=Alumni Association,ou=People,o=Example,c=US" (0x4972608) ==23914== ==23914== Invalid free() / delete / delete[] ==23914== at 0x4004FDA: free (vg_replace_malloc.c:233) ==23914== by 0x826B139: ber_memfree_x (memory.c:152) ==23914== by 0x80F551F: slap_sl_free (sl_malloc.c:481) ==23914== by 0x80C8CE6: do_extended (extended.c:187) ==23914== by 0x808ACB9: connection_operation (connection.c:1109) ==23914== by 0x8234F88: ldap_int_thread_pool_wrapper (tpool.c:685) ==23914== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==23914== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==23914== Address 0x4972608 is 0 bytes inside a block of size 62 free'd ==23914== at 0x4004FDA: free (vg_replace_malloc.c:233) ==23914== by 0x826B139: ber_memfree_x (memory.c:152) ==23914== by 0x80F551F: slap_sl_free (sl_malloc.c:481) ==23914== by 0x80CA4C7: passwd_extop (passwd.c:326) ==23914== by 0x80C8F01: fe_extended (extended.c:225) ==23914== by 0x80C8C06: do_extended (extended.c:177) ==23914== by 0x808ACB9: connection_operation (connection.c:1109) ==23914== by 0x8234F88: ldap_int_thread_pool_wrapper (tpool.c:685) ==23914== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==23914== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==23914== A fix (a hack, at least) is coming. p.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs August 2010