Bug#895450: slapd: segfault in back_mdb

[wferi at niif.hu]

Control: tag -1 - moreinfo

On Wed, 11 Apr 2018 10:08:25 -0700 Ryan Tandy <ryan at nardis.ca> wrote:

> On Wed, Apr 11, 2018 at 06:41:08PM +0200, Ferenc Wágner wrote:
>
>> slapd[4515]: segfault at 4c ip 00007f71abdbfc9b sp 00007f716f184780 error 4 in back_mdb-2.4.so.2.10.7[7f71abdb0000+39000]
>
> Not familiar to me, nor to upstream based on the information provided. 
> Feel free to remove the 'moreinfo' tag if it happens again and you're 
> able to capture a core or stacktrace.

Hi Ryan,

One and a half year later, and I've got a core dump!  Stretch system,
slapd 2.4.44+dfsg-5+deb9u3, segmentation fault at the same point, but
with a different value:

Dec 19 10:31:40 birch slapd[19274]: do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - NEW_COOKIE
Dec 19 10:31:40 birch slapd[19274]: do_syncrep2: rid=001 NEW_COOKIE: rid=001,csn=20191219093138.816310Z#000000#000#000000
Dec 19 10:31:40 birch slapd[19274]: slap_queue_csn: queueing 0x7ff460102d90 20191219093138.816310Z#000000#000#000000
Dec 19 10:31:40 birch slapd[19274]: slap_graduate_commit_csn: removing 0x7ff460102d90 20191219093138.816310Z#000000#000#000000
Dec 19 10:31:59 birch slapd[19274]: do_syncrep2: rid=001 cookie=rid=001,csn=20191219093159.802851Z#000000#000#000000
Dec 19 10:31:59 birch slapd[19274]: syncrepl_message_to_entry: rid=001 DN: uid=jeszenszkya,ou=users,o=niifi,o=niif,c=hu, UUID: 6eb0ba40-14b1-1039-9559-11af45fdb739
Dec 19 10:31:59 birch slapd[19274]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY)
Dec 19 10:31:59 birch slapd[19274]: syncrepl_entry: rid=001 be_search (0)
Dec 19 10:31:59 birch slapd[19274]: syncrepl_entry: rid=001 uid=jeszenszkya,ou=users,o=niifi,o=niif,c=hu
Dec 19 10:31:59 birch slapd[19274]: slap_queue_csn: queueing 0x7ff46c11d760 20191219093159.802851Z#000000#000#000000
Dec 19 10:31:59 birch kernel: [3068983.104734] slapd[19276]: segfault at 80b9542009 ip 00007ff4b7304c9b sp 00007ff47a6c9700 error 4 in back_mdb-2.4.so.2.10.7[7ff4b72f5000+39000]

Some random info that looked useful at first sight:

(gdb) bt
#0  mdb_modify_internal (op=op at entry=0x7ff47a6ca760, tid=tid at entry=0x5652a1c04f50, 
    modlist=0x7ff46c11d8d0, e=e at entry=0x7ff47a6c9850, text=text at entry=0x7ff47a6ca020, 
    textbuf=textbuf at entry=0x7ff47a6c98d0 "\024", textlen=256)
    at ../../../../../servers/slapd/back-mdb/modify.c:99
#1  0x00007ff4b7307f8e in mdb_modrdn (op=0x7ff47a6ca760, rs=0x7ff47a6ca000)
    at ../../../../../servers/slapd/back-mdb/modrdn.c:509
#2  0x00005652a06cb040 in overlay_op_walk (op=op at entry=0x7ff47a6ca760, rs=0x7ff47a6ca000, 
    which=op_modrdn, oi=0x5652a1a2a850, on=<optimized out>)
    at ../../../../servers/slapd/backover.c:677
#3  0x00005652a06cb19d in over_op_func (op=0x7ff47a6ca760, rs=<optimized out>, which=<optimized out>)
    at ../../../../servers/slapd/backover.c:730
#4  0x00005652a06c29df in syncrepl_entry (syncCSN=0x7ff46c115400, syncUUID=0x7ff47a6ca070, 
    syncstate=<optimized out>, modlist=0x7ff47a6c9d30, entry=0x5652a19a8f38, op=0x7ff47a6ca760, 
    si=0x5652a1a39600) at ../../../../servers/slapd/syncrepl.c:3273
#5  do_syncrep2 (op=op at entry=0x7ff47a6ca760, si=si at entry=0x5652a1a39600)
    at ../../../../servers/slapd/syncrepl.c:1040
#6  0x00005652a06c4134 in do_syncrepl (ctx=ctx at entry=0x7ff47a6cac10, arg=arg at entry=0x5652a1a21e90)
    at ../../../../servers/slapd/syncrepl.c:1564
#7  0x00005652a065deed in connection_read_thread (ctx=0x7ff47a6cac10, argv=0xb)
    at ../../../../servers/slapd/connection.c:1296
#8  0x00007ff4bbe3efda in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#9  0x00007ff4ba3a74a4 in start_thread (arg=0x7ff47a6cb700) at pthread_create.c:456
#10 0x00007ff4ba0e9d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

(gdb) p *modlist
$9 = {sml_mod = {sm_desc = 0x5652a198dc00, sm_values = 0x7ff46c11d910, sm_nvalues = 0x7ff46c11d960, 
    sm_numvals = 1, sm_op = 1, sm_flags = 0, sm_type = {bv_len = 0, bv_val = 0x0}}, 
  sml_next = 0x7ff46c11d7f0}
(gdb) p *modlist->sml_next
$10 = {sml_mod = {sm_desc = 0x5652a198dc00, sm_values = 0x7ff46c11d830, sm_nvalues = 0x7ff46c11d880, 
    sm_numvals = 1, sm_op = 4096, sm_flags = 0, sm_type = {bv_len = 0, bv_val = 0x0}}, 
  sml_next = 0x80b9541fed}
(gdb) p mod
$12 = (Modification *) 0x80b9541fed
(gdb) p &mod->sm_op
$13 = (short *) 0x80b9542009

The end of the console output:

$ /usr/sbin/slapd -h ldapi:/// -F /etc/ldap/slapd.d -d Stats,Stats2
[...]
5dfb4079 conn=1001 op=4783 SRCH base="o=niifi,o=niif,c=hu" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=jsj))"
5dfb4079 conn=1001 op=4783 SRCH attr=uidNumber cn gecos uid objectClass homeDirectory gidNumber loginShell
5dfb4079 conn=1001 op=4783 SEARCH RESULT tag=101 err=0 nentries=0 text=
Segmentation fault

I'm ready to extract more info from the core dump or provide the
configuration if needed.  In short, it's a partial replica (constrained
by ACLs) from a wheezy slapd (2.4.40-4~bpo70+2).
-- 
Thanks,
Feri