slapd crash when using SQL backend

Bug #368044 reported by Stephane Chazelas
6
Affects Status Importance Assigned to Milestone
openldap
New
Undecided
Unassigned
openldap (Ubuntu)
Fix Released
Low
Unassigned

Bug Description

I've not narrowed down the minimum scenario that causes it. But the bug is quite obvious from reading the code. There's a free() that should definitely not be called as it is made on an address that is not the result of an allocation.

Please find diff attached (it may not be *the* best/correct solution as I've not deeply analysed why the code was written that way but it seems to fix it for me).

hardy is also affected.

Below is valgrind and gdb information.

The crash occurs when a client connects and does a search. I suppose just setting up openldap with a SQL backend would be enough.

Valgrind:

==>backsql_search(): base="*****************", filter="(objectClass=*)", scope=2, deref=0, attrsonly=0, attributes to load: all
==>backsql_get_db_conn()
==>backsql_open_db_handle()
do_bind: v3 anonymous bind
<==backsql_open_db_handle()
<==backsql_get_db_conn()
==>backsql_dn2id("****MASKED****") matched expected
==>backsql_id2entry()
==32193==
==32193== Thread 4:
==32193== Invalid free() / delete / delete[]
==32193== at 0x4824B4A: free (vg_replace_malloc.c:323)
==32193== by 0x489AE28: ber_memfree_x (memory.c:152)
==32193== by 0x6058F: ch_free (ch_malloc.c:139)
==32193== by 0x53F86BF: backsql_id2entry (entry-id.c:945)
==32193== by 0x53ED183: backsql_init_search (search.c:315)
==32193== by 0x53F1B04: backsql_search (search.c:2034)
==32193== by 0x3F8C8: fe_op_search (search.c:366)
==32193== by 0x3F21B: do_search (search.c:217)
==32193== by 0x3B8F9: connection_operation (connection.c:1084)
==32193== by 0x3BE54: connection_read_thread (connection.c:1211)
==32193== by 0x485219A: ldap_int_thread_pool_wrapper (tpool.c:663)
==32193== by 0x49E750E: start_thread (in /lib/tls/i686/cmov/libpthread-2.8.90.so)
==32193== Address 0x4e31c24 is 444 bytes inside a block of size 40,004 alloc'd
==32193== at 0x4823DE2: calloc (vg_replace_malloc.c:397)
==32193== by 0x489B034: ber_memcalloc_x (memory.c:277)
==32193== by 0x6039A: ch_calloc (ch_malloc.c:104)
==32193== by 0x4A15E: entry_prealloc (entry.c:548)
==32193== by 0x4A22D: entry_alloc (entry.c:575)
==32193== by 0x53EBCDD: read_baseObject (config.c:677)
==32193== by 0x53EAC96: backsql_db_config (config.c:448)
==32193== by 0x2F1BB: read_config_file (config.c:786)
==32193== by 0x23A21: read_config (bconfig.c:3463)
==32193== by 0x18DF7: main (main.c:754)

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb6dddb90 (LWP 426)]
0xb7ee0430 in __kernel_vsyscall ()
(gdb) bt full
#0 0xb7ee0430 in __kernel_vsyscall ()
No symbol table info available.
#1 0xb79f38a0 in raise () from /lib/tls/i686/cmov/libc.so.6
No symbol table info available.
#2 0xb79f5268 in abort () from /lib/tls/i686/cmov/libc.so.6
No symbol table info available.
#3 0xb7a3116d in ?? () from /lib/tls/i686/cmov/libc.so.6
No symbol table info available.
#4 0xb7a37454 in ?? () from /lib/tls/i686/cmov/libc.so.6
No symbol table info available.
#5 0xb7a394b6 in free () from /lib/tls/i686/cmov/libc.so.6
No symbol table info available.
#6 0xb7e54e29 in ber_memfree_x (p=0xb830b13c, ctx=0x0) at /home/stephane/install/DEB/openldap-2.4.11/libraries/liblber/memory.c:152
        __PRETTY_FUNCTION__ = "ber_memfree_x"
#7 0xb7f43590 in ch_free (ptr=0xb830b13c) at /home/stephane/install/DEB/openldap-2.4.11/servers/slapd/ch_malloc.c:139
        ctx = (void *) 0x0
#8 0xb76ef6c0 in backsql_id2entry (bsi=0xb6ddbdb8, eid=0xb6ddbdcc) at /home/stephane/install/DEB/openldap-2.4.11/servers/slapd/back-sql/entry-id.c:945
        e = (Entry *) 0xb830b13c
        op = (Operation *) 0xb836ac40
        bi = (backsql_info *) 0xb82f5358
        i = 1203274741
        rc = -1209131020
        __PRETTY_FUNCTION__ = "backsql_id2entry"
#9 0xb76e4184 in backsql_init_search (bsi=0xb6ddbdb8, nbase=0xb836ac5c, scope=2, stoptime=1240841287, filter=0xb68dc12c, dbh=0xb8385b90, op=0xb836ac40, rs=0xb6ddd12c, attrs=0x0, flags=11)
    at /home/stephane/install/DEB/openldap-2.4.11/servers/slapd/back-sql/search.c:315
        matched = 1
        getentry = 1
        gotit = 1
        bi = (backsql_info *) 0xb82f5358
        rc = 0
        __PRETTY_FUNCTION__ = "backsql_init_search"
#10 0xb76e8b05 in backsql_search (op=0xb836ac40, rs=0xb6ddd12c) at /home/stephane/install/DEB/openldap-2.4.11/servers/slapd/back-sql/search.c:2034
        bi = (backsql_info *) 0xb82f5358
        dbh = (SQLHDBC) 0xb8385b90
        sres = 0
        user_entry = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x0}, e_nname = {bv_len = 0, bv_val = 0x0}, e_attrs = 0x0, e_ocflags = 0, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x0}
        base_entry = {e_id = 0, e_name = {bv_len = 17, bv_val = 0xb8359908 "****MASKED****"}, e_nname = {bv_len = 17, bv_val = 0xb8359340 "****MASKED****"}, e_attrs = 0xb83169cc,
  e_ocflags = 0, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x0}
        manageDSAit = 0
        stoptime = 1240841287
        bsi = {bsi_op = 0xb836ac40, bsi_rs = 0xb6ddd12c, bsi_flags = 1, bsi_base_ndn = 0xb836ac5c, bsi_use_subtree_shortcut = 0, bsi_base_id = {eid_id = 0, eid_keyval = 0, eid_oc_id = 0,
    eid_oc = 0x0, eid_dn = {bv_len = 17, bv_val = 0xb68dc16c "****MASKED****"}, eid_ndn = {bv_len = 17, bv_val = 0xb68dc154 "****MASKED****"}, eid_next = 0x0}, bsi_scope = 2,
  bsi_filter = 0xb68dc12c, bsi_stoptime = 1240841287, bsi_id_list = 0x0, bsi_id_listtail = 0xb6ddbdfc, bsi_c_eid = 0x0, bsi_n_candidates = 0, bsi_status = 0, bsi_oc = 0x0, bsi_sel = {
    bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_from = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_join_where = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0},
  bsi_flt_where = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_filter_oc = 0x0, bsi_dbh = 0xb8385b90, bsi_attrs = 0x0, bsi_e = 0xb6ddbeb8}
        eid = (backsql_entryID *) 0x0
        nbase = {bv_len = 0, bv_val = 0x0}
        lastid = 0
#11 0xb7f228c9 in fe_op_search (op=0xb836ac40, rs=0xb6ddd12c) at /home/stephane/install/DEB/openldap-2.4.11/servers/slapd/search.c:366
        bd = (BackendDB *) 0xb8036a20
#12 0xb7f2221c in do_search (op=0xb836ac40, rs=0xb6ddd12c) at /home/stephane/install/DEB/openldap-2.4.11/servers/slapd/search.c:217
        base = {bv_len = 17, bv_val = 0xb836d14f "****MASKED****"}
        siz = 0
        off = 0
        i = 0
#13 0xb7f1e8fa in connection_operation (ctx=0xb6ddd21c, arg_v=0xb836ac40) at /home/stephane/install/DEB/openldap-2.4.11/servers/slapd/connection.c:1084
        rc = 80
---Type <return> to continue, or q <return> to quit---
        op = (Operation *) 0xb836ac40
        rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_sasl = {r_sasldata = 0x0},
    sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0}
        tag = 99
        opidx = SLAP_OP_SEARCH
        conn = (Connection *) 0xb767f0e8
        memctx = (void *) 0xb836d120
        memctx_null = (void *) 0x0
        memsiz = 1048576
        __PRETTY_FUNCTION__ = "connection_operation"
#14 0xb7f1ee55 in connection_read_thread (ctx=0xb6ddd21c, argv=0xc) at /home/stephane/install/DEB/openldap-2.4.11/servers/slapd/connection.c:1211
        rc = 0
        cri = {op = 0xb836ac40, func = 0, arg = 0x0, ctx = 0xb6ddd21c, nullop = 0}
        s = 12
#15 0xb7e6919b in ldap_int_thread_pool_wrapper (xpool=0xb82e28c8) at /home/stephane/install/DEB/openldap-2.4.11/libraries/libldap_r/tpool.c:663
        pool = (struct ldap_int_thread_pool_s *) 0xb82e28c8
        task = (ldap_int_thread_task_t *) 0xb83200d0
        work_list = (ldap_int_tpool_plist_t *) 0xb82e2948
        ctx = {ltu_id = 3067992976, ltu_key = {{ltk_key = 0xb7f1e444, ltk_data = 0xb836d030, ltk_free = 0xb7f1e217 <conn_counter_destroy>}, {ltk_key = 0xb7f8b659, ltk_data = 0xb836d120,
      ltk_free = 0xb7f8b480 <slap_sl_mem_destroy>}, {ltk_key = 0xb7f38ea7, ltk_data = 0x0, ltk_free = 0xb7f38e04 <slap_op_q_destroy>}, {ltk_key = 0xb770b410, ltk_data = 0xb8385b90,
      ltk_free = 0xb76f4b23 <backsql_db_conn_keyfree>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>}}
        kctx = (ldap_int_thread_userctx_t *) 0x0
        i = 32
        keyslot = 734
        hash = 5416670
        __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper"
#16 0xb7cf950f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
No symbol table info available.
#17 0xb7aa9a0e in clone () from /lib/tls/i686/cmov/libc.so.6
No symbol table info available.

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 8.10
NonfreeKernelModules: nvidia
Package: slapd 2.4.11-0ubuntu6
ProcEnviron:
 SHELL=/bin/zsh
 PATH=/home/username/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/var/lib/gems/1.8/bin:/var/lib/gems/1.9.0/bin
 LANG=en_GB.UTF-8
SourcePackage: openldap
Uname: Linux 2.6.27-14-generic i686

Revision history for this message
Stephane Chazelas (stephane-chazelas) wrote :
Revision history for this message
Stephane Chazelas (stephane-chazelas) wrote :

I'm not seeing the patch, so I attach it again. Sorry if that causes a duplicate.

Revision history for this message
Chuck Short (zulcss) wrote :

Hi,

I was wondering where does this patch comes from?

Thanks
chuck

Changed in openldap (Ubuntu):
status: New → Triaged
importance: Undecided → Low
Revision history for this message
Stephane Chazelas (stephane-chazelas) wrote :

What do you mean by "where does it come from?". I comes from me some time ago.

Why classify as low? Is it because the sql backend isn't supported?

Cheers,
Stephane

Revision history for this message
Mathias Gug (mathiaz) wrote : Re: [Bug 368044] Re: slapd crash when using SQL backend

On Thu, Oct 08, 2009 at 08:56:13AM -0000, Stephane Chazelas wrote:
> What do you mean by "where does it come from?". I comes from me some
> time ago.
>

Could you please report this bug upstream [1] and check whether your patch
would make sense upstream?

[1]: http://www.openldap.org/its/

> Why classify as low? Is it because the sql backend isn't supported?
>

See https://wiki.ubuntu.com/Bugs/Importance

Low:
 * Ones that affect unusual configurations

--
Mathias Gug
Ubuntu Developer http://www.ubuntu.com

Revision history for this message
Ryan Tandy (rtandy) wrote :

Hi,

This appears to be the same as ITS#6172 upstream, fixed in 2.4.18, so Karmic and later. Therefore, marking Fix Released.

Changed in openldap (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.