#47360 Delete attribute could crash the server
Closed: wontfix None Opened 7 years ago by nhosoi.

It was found when disabling NT User Attribute of a user sync'ed from AD on Console. But the fact it is an NT user should not be so important. If you disable NT User Attribute, it deletes quite a number of attributes at once, which is more essential in this crash, I think.

An error in the error log:
[14/May/2013:12:42:31 -0700] - entry2str_internal_ext: array boundary wrote: bufsize=1606 wrote=1893

Stack trace (note: it is a debug build)

Program received signal SIGABRT, Aborted.
0x00000032ece35935 in raise () from /usr/lib64/libc.so.6
(gdb) bt
#0  0x00000032ece35935 in raise () from /usr/lib64/libc.so.6
#1  0x00000032ece370e8 in abort () from /usr/lib64/libc.so.6
#2  0x00000032ece74e8b in __libc_message () from /usr/lib64/libc.so.6
#3  0x00000032ece7c00e in _int_free () from /usr/lib64/libc.so.6
#4  0x00000033ebc4f74d in slapi_ch_free (ptr=0x7f0a9b3f7500)
    at ldap/servers/slapd/ch_malloc.c:363
#5  0x00007f0aa7502f04 in id2entry_add_ext (be=0xb01d80, e=0x7f0a70005640, 
    txn=0x7f0a9b3f7630, encrypt=1, cache_res=0x7f0a9b3f75c4)
    at ldap/servers/slapd/back-ldbm/id2entry.c:140
#6  0x00007f0aa753c50e in ldbm_back_modify (pb=0x7f0a9b3fbaa0)
    at ldap/servers/slapd/back-ldbm/ldbm_modify.c:615
#7  0x00000033ebc95895 in op_shared_modify (pb=0x7f0a9b3fbaa0, pw_change=0, 
    old_pw=0x0) at ldap/servers/slapd/modify.c:1075
#8  0x00000033ebc940a8 in do_modify (pb=0x7f0a9b3fbaa0)
    at ldap/servers/slapd/modify.c:415
#9  0x0000000000414d86 in connection_dispatch_operation (conn=0x7f0aa1219f48, 
    op=0xda6ac0, pb=0x7f0a9b3fbaa0) at ldap/servers/slapd/connection.c:652
#10 0x00000000004169ab in connection_threadmain ()
    at ldap/servers/slapd/connection.c:2479
#11 0x0000003155a28cf3 in _pt_root (arg=0xd77670)
    at ../../../mozilla/nsprpub/pr/src/pthreads/ptthread.c:156
#12 0x00000032ed207d14 in start_thread () from /usr/lib64/libpthread.so.0
#13 0x00000032ecef168d in clone () from /usr/lib64/libc.so.6

Output from valgrind:

==28851== Thread 18:
==28851== Invalid write of size 1
==28851==    at 0x4A0A2A3: memcpy@@GLIBC_2.14 (mc_replace_strmem.c:881)
==28851==    by 0x3157E41F6E: ldif_sput_wrap (string3.h:105)
==28851==    by 0x33EBC749B4: slapi_ldif_put_type_and_value_with_options (ldaputil.c:461)
==28851==    by 0x33EBC62C8F: entry2str_internal_put_value (entry.c:1635)
==28851==    by 0x33EBC62D44: entry2str_internal_put_valueset (entry.c:1650)
==28851==    by 0x33EBC6301E: entry2str_internal_put_attrlist (entry.c:1731)
==28851==    by 0x33EBC634D8: entry2str_internal_ext (entry.c:1883)
==28851==    by 0x33EBC6363A: slapi_entry2str_with_options (entry.c:1948)
==28851==    by 0x8F4EE7D: id2entry_add_ext (id2entry.c:126)
==28851==    by 0x8F8850D: ldbm_back_modify (ldbm_modify.c:615)
==28851==    by 0x33EBC95894: op_shared_modify (modify.c:1075)
==28851==    by 0x33EBC940A7: do_modify (modify.c:415)
==28851==  Address 0x7752306 is 0 bytes after a block of size 1,606 alloc'd
==28851==    at 0x4A0881C: malloc (vg_replace_malloc.c:270)
==28851==    by 0x33EBC4F25B: slapi_ch_malloc (ch_malloc.c:155)
==28851==    by 0x33EBC63411: entry2str_internal_ext (entry.c:1863)
==28851==    by 0x33EBC6363A: slapi_entry2str_with_options (entry.c:1948)
==28851==    by 0x8F4EE7D: id2entry_add_ext (id2entry.c:126)
==28851==    by 0x8F8850D: ldbm_back_modify (ldbm_modify.c:615)
==28851==    by 0x33EBC95894: op_shared_modify (modify.c:1075)
==28851==    by 0x33EBC940A7: do_modify (modify.c:415)
==28851==    by 0x414D85: connection_dispatch_operation (connection.c:652)
==28851==    by 0x4169AA: connection_threadmain (connection.c:2479)
==28851==    by 0x3155A28CF2: _pt_root (ptthread.c:156)
==28851==    by 0x32ED207D13: start_thread (in /usr/lib64/libpthread-2.15.so)

I wonder the allocated length (elen) is not large enough to store the deleted attribute values with the state info? That is, the attribute value length with delete state info is longer than the original?

1813 static char *
1814 entry2str_internal_ext( Slapi_Entry *e, int *len, int entry2str_ctrl)
1863         ecur = ebuf = (char *)slapi_ch_malloc(elen);
        ecur = ebuf = (char *)slapi_ch_malloc(elen);
1880         /* Put the deleted attributes */
1881         if(entry2str_ctrl & SLAPI_DUMP_STATEINFO)
1882         {
1883             entry2str_internal_put_attrlist(e->e_deleted_attrs,
1884                                             ATTRIBUTE_DELETED, entry2str_ctrl,
1885                                             &ecur, &typebuf, &typebuf_len );
1886         }

Here is the current status

  • because of the log (entry2str_internal_ext: array boundary wrote: bufsize=1606 wrote=1893)
    we know that allocated buffer was not large enough to fit all the wrote characters. Also the difference is large (almost 300 bytes). If we remove ~ 300 values, it could be the result of a missing last '\0' character or something like that.

  • Reading the code I did not find anything suspicious (not a surprise :) )

Here are the next steps

  • I do not know if the problem is reproducible, I will try with a simple test case. But as this is in a very used portion of code, I doubt I will be able to reproduce.

  • Have to check if the core is still available

Here is the current status

  • I failed to reproduce the problem. I tested with various kind of rdn (single/multivalued '+'), with rdn containing '"' and escaped characters. For all the tests the amount of booked memory was larger than the amount of written bytes. I also unsuccessfully tried with empty attributes value, base64 encoded and encrypted.

Here are the next steps

  • check if the core is still available
  • try to reproduce with some samples of such entries and config (schema/dse.ldif

Metadata Update from @tbordaz:
- Issue assigned to nhosoi
- Issue set to the milestone: 1.3.2 - 06/13 (June)

4 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/697

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Duplicate)

7 months ago

Login to comment on this ticket.