(ITS#5733) core dump in re24's slapd-ldap(5)

[ando@sys-net.it]

Full_Name: Pierangelo Masarati
Version: re24
OS: Linux x86
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (81.72.89.40)
Submitted by: ando


I had a strange core dump while testing re24 (test039).  I'm reporting it in
order to be able to investigate it further later.  Backtrace follows:

(gdb) bt
#0  0x00800402 in __kernel_vsyscall ()
#1  0x00c9ad20 in raise () from /lib/libc.so.6
#2  0x00c9c631 in abort () from /lib/libc.so.6
#3  0x00c9416b in __assert_fail () from /lib/libc.so.6
#4  0x0817c7e5 in ldap_back_conn_delete (li=0x8a9ef30, lc=0x8b55df8) at
bind.c:157
#5  0x0817d20a in ldap_back_freeconn (li=0x8a9ef30, lc=0x8b55df8, dolock=0) at
bind.c:467
#6  0x0817e8cf in ldap_back_release_conn_lock (li=0x8a9ef30, lcp=0xb4376d10,
dolock=1) at bind.c:1144
#7  0x0817cf12 in ldap_back_bind (op=0x8b973e0, rs=0xb4377128) at bind.c:355
#8  0x080fac38 in overlay_op_walk (op=0x8b973e0, rs=0xb4377128, which=op_bind,
oi=0x8a82d78, on=0x0) at backover.c:667
#9  0x080faded in over_op_func (op=0x8b973e0, rs=0xb4377128, which=op_bind) at
backover.c:719
#10 0x080fae2d in over_op_bind (op=0x8b973e0, rs=0xb4377128) at backover.c:729
#11 0x080a8311 in fe_op_bind (op=0x8b973e0, rs=0xb4377128) at bind.c:383
#12 0x080fac38 in overlay_op_walk (op=0x8b973e0, rs=0xb4377128, which=op_bind,
oi=0x8a85090, on=0x0) at backover.c:667
#13 0x080faded in over_op_func (op=0x8b973e0, rs=0xb4377128, which=op_bind) at
backover.c:719
#14 0x080fae2d in over_op_bind (op=0x8b973e0, rs=0xb4377128) at backover.c:729
#15 0x080a7aa7 in do_bind (op=0x8b973e0, rs=0xb4377128) at bind.c:205
#16 0x08083c40 in connection_operation (ctx=0xb4377210, arg_v=0x8b973e0) at
connection.c:1084
#17 0x0808411a in connection_read_thread (ctx=0xb4377210, argv=0x1f) at
connection.c:1210
#18 0x08207d35 in ldap_int_thread_pool_wrapper (xpool=0x8a595b8) at tpool.c:663
#19 0x00deb46b in start_thread () from /lib/libpthread.so.0
#20 0x00d42dbe in clone () from /lib/libc.so.6
(gdb) f 4
#4  0x0817c7e5 in ldap_back_conn_delete (li=0x8a9ef30, lc=0x8b55df8) at
bind.c:157
157				assert( !LDAP_BACK_CONN_TAINTED( lc ) );
(gdb) p *lc
$1 = {lc_conn = 0xb7e91ba0, lc_ld = 0x8b79160, lc_cred = {bv_len = 0, bv_val =
0x0}, lc_bound_ndn = {bv_len = 68, 
    bv_val = 0x8b2dce8 "cn=james a jones 1,ou=alumni
association,ou=people,dc=example,dc=com"}, lc_local_ndn = {bv_len = 68, 
    bv_val = 0x8b37e28 "cn=james a jones 1,ou=alumni
association,ou=people,dc=example,dc=com"}, lc_lcflags = 289, lc_refcnt = 0,
lc_flags = 4096, 
  lc_create_time = 0, lc_time = 0, lc_q = {tqe_next = 0x0, tqe_prev = 0x0}}
(gdb) p /x lc->lc_lcflags
$2 = 0x121

The connection is simultaneously cached (0x100) and tainted (0x20); this
triggers an assert.  Note that 

(gdb) f 7
#7  0x0817cf12 in ldap_back_bind (op=0x8b973e0, rs=0xb4377128) at bind.c:355
355			ldap_back_release_conn( li, lc );
(gdb) p retrying 
$4 = LDAP_BACK_RETRYING

so apparently no one had a chance to taint the connection (from within this
thread).  Probably, the assert is too tight.  Either tainting and uncaching
should occur simultaneously, or the assert should just be relaxed.

p.