Viewing Incoming/5733
Full headers

Major security issue: yes  no

Notes:
needs investigation
Notification:

Date: Thu, 9 Oct 2008 20:42:58 GMT
From: ando@sys-net.it
To: openldap-its@OpenLDAP.org
Subject: core dump in re24's slapd-ldap(5)

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.

Followup 1

Date: Wed, 18 Mar 2009 12:32:22 -0700
From: Quanah Gibson-Mount <quanah@zimbra.com>
To: ando@sys-net.it, openldap-its@openldap.org
Subject: Re: (ITS#5733) core dump in re24's slapd-ldap(5)

--On Thursday, October 09, 2008 8:42 PM +0000 ando@sys-net.it wrote:

> 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:

I hit this today in testing RE24 as well:

Thread 1 (process 27053):
#0  0x000000395e030155 in raise () from /lib64/libc.so.6
#1  0x000000395e031bf0 in abort () from /lib64/libc.so.6
#2  0x000000395e0295d6 in __assert_fail () from /lib64/libc.so.6
#3  0x00002b45fe1d3f51 in ldap_back_conn_delete (li=0xba73080, 
lc=0x2aaab0003690) at ../../../../servers/slapd/back-ldap/bind.c:157
#4  0x00002b45fe1d4a34 in ldap_back_freeconn (li=0xba73080, 
lc=0x2aaab0003690, dolock=0) at 
../../../../servers/slapd/back-ldap/bind.c:467
#5  0x00002b45fe1d6492 in ldap_back_release_conn_lock (li=0xba73080, 
lcp=0x45b9c5e8, dolock=1) at ../../../../servers/slapd/back-ldap/bind.c:1144
#6  0x00002b45fe1d46b0 in ldap_back_bind (op=0xc168af0, rs=0x45b9cc40) at 
../../../../servers/slapd/back-ldap/bind.c:355
#7  0x00000000004c24da in overlay_op_walk (op=0xc168af0, rs=0x45b9cc40, 
which=op_bind, oi=0xba2cd90, on=0x0) at 
../../../servers/slapd/backover.c:669
#8  0x00000000004c26dd in over_op_func (op=0xc168af0, rs=0x45b9cc40, 
which=op_bind) at ../../../servers/slapd/backover.c:721
#9  0x00000000004c272b in over_op_bind (op=0xc168af0, rs=0x45b9cc40) at 
../../../servers/slapd/backover.c:731
#10 0x0000000000460681 in fe_op_bind (op=0xc168af0, rs=0x45b9cc40) at 
../../../servers/slapd/bind.c:383
#11 0x00000000004c24da in overlay_op_walk (op=0xc168af0, rs=0x45b9cc40, 
which=op_bind, oi=0xba6def0, on=0x0) at 
../../../servers/slapd/backover.c:669
#12 0x00000000004c26dd in over_op_func (op=0xc168af0, rs=0x45b9cc40, 
which=op_bind) at ../../../servers/slapd/backover.c:721
#13 0x00000000004c272b in over_op_bind (op=0xc168af0, rs=0x45b9cc40) at 
../../../servers/slapd/backover.c:731
#14 0x000000000045fdb0 in do_bind (op=0xc168af0, rs=0x45b9cc40) at 
../../../servers/slapd/bind.c:205
#15 0x0000000000438a70 in connection_operation (ctx=0x45b9cd90, 
arg_v=0xc168af0) at ../../../servers/slapd/connection.c:1097
#16 0x0000000000438f8b in connection_read_thread (ctx=0x45b9cd90, 
argv=0x17) at ../../../servers/slapd/connection.c:1223
#17 0x00002b45fad8b6b7 in ldap_int_thread_pool_wrapper (xpool=0xba14330) at 
../../../libraries/libldap_r/tpool.c:663
#18 0x00002b45fb5442f7 in start_thread () from /lib64/libpthread.so.0
#19 0x000000395e0d1e3d in clone () from /lib64/libc.so.6
(gdb) frame 6
#6  0x00002b45fe1d46b0 in ldap_back_bind (op=0xc168af0, rs=0x45b9cc40) at 
../../../../servers/slapd/back-ldap/bind.c:355
355                     ldap_back_release_conn( li, lc );
(gdb) p retrying
$1 = LDAP_BACK_RETRYING
(gdb) frame 3
#3  0x00002b45fe1d3f51 in ldap_back_conn_delete (li=0xba73080, 
lc=0x2aaab0003690) at ../../../../servers/slapd/back-ldap/bind.c:157
157                             assert( !LDAP_BACK_CONN_TAINTED( lc ) );
(gdb) print *lc
$2 = {lc_conn = 0x2b45fea45f50, lc_ld = 0x2aaab00126d0, lc_cred = {bv_len = 
0, bv_val = 0x0}, lc_bound_ndn = {bv_len = 46,
    bv_val = 0x2aaaac126130 "cn=james a jones 
4,ou=people,dc=example,dc=com"}, lc_local_ndn = {bv_len = 46, bv_val = 
0x2aaaac1192a0 "cn=james a jones 4,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
$3 = 0x121

--Quanah


--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra ::  the leader in open source messaging and collaboration

Followup 2

Date: Sat, 20 Jun 2009 19:00:21 -0400 (EDT)
From: Aaron Richton <richton@nbcs.rutgers.edu>
To: openldap-its@openldap.org
Subject: (ITS#5733) tainted connection

I saw this three times in testing of HEAD. One backtrace and -d -1:

https://www.nbcs.rutgers.edu/~richton/test039-bt-200906200640.txt
https://www.nbcs.rutgers.edu/~richton/test039-slapdlog-200906200640.txt


These are under libumem with transaction logging enabled. All malloc/free 
for a given block can be retrieved, in theory...