OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Incoming/6556
Full headers

From: dieter@dkluenter.de
Subject: test031 core dumps after applying first filter
Compose comment
Download message
State:
0 replies:
3 followups: 1 2 3

Major security issue: yes  no

Notes:

Notification:


Date: Sun, 23 May 2010 13:29:29 +0000
From: dieter@dkluenter.de
To: openldap-its@OpenLDAP.org
Subject: test031 core dumps after applying first filter
Full_Name: Dieter Kluenter
Version: HEAD
OS: openSuSE
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (84.142.11.71)


I have enabled slapd-modules/comp_match and properly installed all relevant
files to tests/data/comp_libs. When running test031, slapd segfaults:

Running ./scripts/test031-component-filter for bdb...
running defines.sh
Running slapadd to build slapd database...
Running slapindex to index slapd database...
Starting slapd on TCP/IP port 9011...
Testing slapd searching...
Testing Component Filter Match RFC3687 Certificate searching:
        f=(userCertificate:componentFilterMatch:=item:{ component
"toBeSigned.serialNumber", rule allComponen
tsMatch, value 0 }) ...
        f=(userCertificate:componentFilterMatch:=item:{ component
"toBeSigned.version", rule allComponentsMat
ch, value 2 }) ...
./scripts/test031-component-filter: Zeile 105:  5312 Speicherzugriffsfehler 
(Speicherabzug geschrieben) $SLA
PD -f $ADDCONF -h $URI1 -d $LVL $TIMING > $LOG1 2>&1
ldapsearch failed (255)!
./scripts/test031-component-filter: Zeile 110: kill: (5312) - Kein passender
Prozess gefunden

(gdb) core-file core
Core was generated by `/home/dieter/build/openldap/servers/slapd/.libs/lt-slapd
-s0 -f /home/dieter/bu'.
Program terminated with signal 11, Segmentation fault.
(gdb) file /home/dieter/build/openldap/servers/slapd/.libs/lt-slapd 
Reading symbols from
/home/dieter/build/openldap/servers/slapd/.libs/lt-slapd...done.
(gdb) where
#0  0x080e6525 in slap_sl_free (ptr=0x87ba173, ctx=0x89aa3c0) at
sl_malloc.c:492
#1  0x080a0f5b in ch_free (ptr=0x87ba173) at ch_malloc.c:137
#2  0x080e3e3a in mra_free (op=0x89adc80, mra=0x87ba218, freeit=1) at mra.c:43
#3  0x08085621 in filter_free_x (op=0x89adc80, f=0x87ba258, freeme=1) at
filter.c:556
#4  0x0808373e in do_search (op=0x89adc80, rs=0xb71190c4) at search.c:230
#5  0x080805f9 in connection_operation (ctx=0xb7119198, arg_v=0x89adc80) at
connection.c:1109
#6  0x08080b18 in connection_read_thread (ctx=0xb7119198, argv=0x11) at
connection.c:1245
#7  0xb7f963b7 in ?? ()
#8  0xb7cf86e5 in ?? ()

(gdb) bt full
#0  0x080e6525 in slap_sl_free (ptr=0x87ba173, ctx=0x89aa3c0) at
sl_malloc.c:492
        sh = 0x89aa3c0
        size = 543520108
        p = 0x87ba16f
        nextp = 0x28e116db
        tmpp = 0xb7119198
        __PRETTY_FUNCTION__ = "slap_sl_free"
#1  0x080a0f5b in ch_free (ptr=0x87ba173) at ch_malloc.c:137
        ctx = 0x89aa3c0
#2  0x080e3e3a in mra_free (op=0x89adc80, mra=0x87ba218, freeit=1) at mra.c:43
No locals.
#3  0x08085621 in filter_free_x (op=0x89adc80, f=0x87ba258, freeme=1) at
filter.c:556
        p = 0x8214680
        next = 0x89adcac
#4  0x0808373e in do_search (op=0x89adc80, rs=0xb71190c4) at search.c:230
        base = {bv_len = 17, bv_val = 0x89aff28 "dc=example,dc=com"}
        siz = 0
        off = 0
        i = 0
#5  0x080805f9 in connection_operation (ctx=0xb7119198, arg_v=0x89adc80) at
connection.c:1109
        rc = 80
        cancel = 0
        op = 0x89adc80
        rs = {sr_type = REP_RESULT, sr_tag = 101, sr_msgid = 2, sr_err = 0,
sr_matched = 0x0, 
          sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search =
{r_entry = 0x0, 
              r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0,
r_nentries = 2, r_v2ref = 0x0}, 
            sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0,
r_rspdata = 0x0}}, sr_flags = 0}
        tag = 99
        opidx = SLAP_OP_SEARCH
        conn = 0x8433e04
        memctx = 0x89aa3c0
        memctx_null = 0x0
        memsiz = 1048576
        __PRETTY_FUNCTION__ = "connection_operation"
#6  0x08080b18 in connection_read_thread (ctx=0xb7119198, argv=0x11) at
connection.c:1245
---Type <return> to continue, or q <return> to quit---
        rc = 0
        cri = {op = 0x89adc80, func = 0, arg = 0x0, ctx = 0xb7119198, nullop =
0}
        s = 17
#7  0xb7f963b7 in ?? ()
No symbol table info available.
#8  0xb7cf86e5 in ?? ()
No symbol table info available.
(gdb) 

-Dieter


Followup 1

Download message
From: "Dieter Kluenter" <dieter@dkluenter.de>
To: openldap-its@openldap.org
Subject: Re: (ITS#6556) test031 core dumps after applying first filter
Date: Thu, 27 May 2010 12:30:51 +0200
Hi,
I have run slapd in valgrind now. The full log kan be found here:
http://pastebin.de/6914
In short, valgrind reported following error:
=20
=3D15353=3D=3D 1 errors in context 1 of 5:
=3D=3D15353=3D=3D Invalid write of size 4
=3D=3D15353=3D=3D    at 0x80E64B5: slap_sl_free (sl_malloc.c:492)
=3D=3D15353=3D=3D    by 0x80A0EEA: ch_free (ch_malloc.c:137)
=3D=3D15353=3D=3D    by 0x80E3DC9: mra_free (mra.c:43)
=3D=3D15353=3D=3D    by 0x80855B0: filter_free_x (filter.c:556)
=3D=3D15353=3D=3D    by 0x80836CD: do_search (search.c:230)
=3D=3D15353=3D=3D    by 0x8080588: connection_operation (connection.c:1109)
=3D=3D15353=3D=3D    by 0x403B376: ldap_int_thread_pool_wrapper (tpool.c:68=
5)
=3D=3D15353=3D=3D    by 0x43046E4: start_thread (in /lib/libpthread-2.10.1.=
so)
=3D=3D15353=3D=3D    by 0x43045FF: ??? (in /lib/libpthread-2.10.1.so)
=3D=3D15353=3D=3D  Address 0x843692b1 is not stack'd, malloc'd or (recently=
) free'd

-Dieter

--=20
Dieter Kl=C3=BCnter | Systemberatung
sip: +49.40.20932173
http://www.dpunkt.de/buecher/2104.html
GPG Key ID:8EF7B6C6



Followup 2

Download message
Subject: Re: (ITS#6556) test031 core dumps after applying first filter
From: Dieter Kluenter <dieter@dkluenter.de>
To: openldap-its@OpenLDAP.org
Cc: dieter@dkluenter.de
Date: Thu, 27 May 2010 12:12:33 +0200
Hi,
I have run slapd in valgrind now, which produced following error:

==15353== 1 errors in context 1 of 5:
==15353== Invalid write of size 4
==15353==    at 0x80E64B5: slap_sl_free (sl_malloc.c:492)
==15353==    by 0x80A0EEA: ch_free (ch_malloc.c:137)
==15353==    by 0x80E3DC9: mra_free (mra.c:43)
==15353==    by 0x80855B0: filter_free_x (filter.c:556)
==15353==    by 0x80836CD: do_search (search.c:230)
==15353==    by 0x8080588: connection_operation (connection.c:1109)
==15353==    by 0x403B376: ldap_int_thread_pool_wrapper (tpool.c:685)
==15353==    by 0x43046E4: start_thread (in /lib/libpthread-2.10.1.so)
==15353==    by 0x43045FF: ??? (in /lib/libpthread-2.10.1.so)
==15353==  Address 0x843692b1 is not stack'd, malloc'd or (recently)
free'd

Full valgrind log can be found at
http://pastebin.de/6914

-Dieter



Followup 3

Download message
Date: Mon, 15 Nov 2010 13:25:09 +0100
From: Ivan Nejgebauer <ian@uns.ac.rs>
To: openldap-its@OpenLDAP.org
Cc: dieter@dkluenter.de
Subject: Re: (ITS#6556) test031 core dumps after applying first filter
slap_sl_free dumps core here because it gets passed a bogus bv_val (from 
the ma_value field of an instance of struct MatchingRuleAssertion). As far 
as I can see, the original bv_val gets clobbered in get_comp_filter 
(servers/slapd/component.c), line 350:

     bv->bv_val = cav.cav_ptr;

Commenting that line out fixes the core dump. I suspect that the 
assignment is there to support nested component filters (see lines 1039 et 
seq. in the same file).

Earlier versions of OpenLDAP had different logic in slap_sl_free, which 
skipped the offending pointer (and thus probably leaving a memory leak).

i.


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org