Bug 1498980 - heap corruption during import.
Summary: heap corruption during import.
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.4
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: mreynolds
QA Contact: Viktor Ashirov
Marc Muehlfeld
Depends On:
Blocks: 1511940
TreeView+ depends on / blocked
Reported: 2017-10-05 17:39 UTC by German Parente
Modified: 2021-03-11 15:55 UTC (History)
6 users (show)

Fixed In Version: 389-ds-base-
Doc Type: Bug Fix
Doc Text:
A buffer overflow has been fixed in Directory Server Previously, if you configured an attribute to be indexed and imported an entry that contained a large binary value into this attribute, the server terminated unexpectedly due to an buffer overflow. The buffer has been fixed. As a result, the server works as expected in the mentioned scenario.
Clone Of:
: 1511940 (view as bug list)
Last Closed: 2018-04-10 14:21:13 UTC
Target Upstream Version:

Attachments (Terms of Use)
valgrind report (5.04 MB, text/plain)
2017-10-05 17:39 UTC, German Parente
no flags Details
new valgrind output (4.31 MB, text/plain)
2017-10-13 13:38 UTC, German Parente
no flags Details

System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 2500 0 None None None 2020-09-13 22:04:00 UTC
Red Hat Product Errata RHBA-2018:0811 0 None None None 2018-04-10 14:22:03 UTC

Description German Parente 2017-10-05 17:39:22 UTC
Created attachment 1334923 [details]
valgrind report

Description of problem:

there's a heap corruption during import of RDS10 from RHDS9:

These are the two active working threads:

(gdb) thread 2
[Switching to thread 2 (LWP 2379)]
#0  0x00007f60a7d74ce7 in __GI_strtol (nptr=0x562e06215540 "14051", endptr=endptr@entry=0x0, base=base@entry=10) at ../stdlib/strtol.c:109
109	  return INTERNAL (__strtol_l) (nptr, endptr, base, 0, _NL_CURRENT_LOCALE);
(gdb) bt
#0  0x00007f60a7d74ce7 in __GI_strtol (nptr=0x562e06215540 "14051", endptr=endptr@entry=0x0, base=base@entry=10) at ../stdlib/strtol.c:109
#1  0x00007f60aa8837ca in atol (__nptr=<optimized out>) at /usr/include/stdlib.h:285
#2  slapi_value_get_ulong (value=0x562e07bc97e0) at ldap/servers/slapd/value.c:458
#3  0x00007f60aa80bd6f in slapi_entry_attr_get_ulong (e=<optimized out>, type=type@entry=0x7f609efa7a6b "parentid") at ldap/servers/slapd/entry.c:2941
#4  0x00007f609ef57ac9 in id2entry_add_ext (be=be@entry=0x562dfdced400, e=0x562e05d2f660, txn=txn@entry=0x0, encrypt=<optimized out>, cache_res=cache_res@entry=0x0)
    at ldap/servers/slapd/back-ldbm/id2entry.c:121
#5  0x00007f609ef67518 in import_foreman (param=0x562e029ac780) at ldap/servers/slapd/back-ldbm/import-threads.c:2669
#6  0x00007f60a8bb19bb in _pt_root (arg=0x562e02b03320) at ../../../nspr/pr/src/pthreads/ptthread.c:216
#7  0x00007f60a8551e25 in start_thread (arg=0x7f6039b12700) at pthread_create.c:308
#8  0x00007f60a7e3334d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113

(gdb) thread 1
[Switching to thread 1 (LWP 2403)]
#0  __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:2079
2079		mov	 %r11, -18(%rdi)
(gdb) bt
#0  __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:2079
#1  0x00007f609ef69caf in memcpy (__len=18, __src=<optimized out>, __dest=0x7f602dafafff) at /usr/include/bits/string3.h:51
#2  encode (data=data@entry=0x7f602daf76d0, 
    buf=buf@entry=0x7f602daf7710 "=0\\82'h0\\82&P\\02\\01\\010`\\a1^0\\\\\\a4Z0X1\\0b0\\09\\06\\03U\\04\\06\\13\\02US1\\100\\0e\\06\\03U\\04\\0a\\13\\07Entrust1\\\"0 \\06\\03U\\04\\0b\\13\\19Certification Authorities1\\130\\11\\06\\03U\\04\\0b\\13\\0aDComRootCA0h\\a0f0d0\\\\\\a4"...) at ldap/servers/slapd/back-ldbm/index.c:806
#3  0x00007f609ef6bdc7 in encoded (d=0x7f602daf76e0, d=0x7f602daf76e0, 
    buf=0x7f602daf7710 "=0\\82'h0\\82&P\\02\\01\\010`\\a1^0\\\\\\a4Z0X1\\0b0\\09\\06\\03U\\04\\06\\13\\02US1\\100\\0e\\06\\03U\\04\\0a\\13\\07Entrust1\\\"0 \\06\\03U\\04\\0b\\13\\19Certification Authorities1\\130\\11\\06\\03U\\04\\0b\\13\\0aDComRootCA0h\\a0f0d0\\\\\\a4"...) at ldap/servers/slapd/back-ldbm/index.c:844
#4  addordel_values_sv (be=0x562dfdced400, db=0x562e07246c00, indextype=<optimized out>, vals=<optimized out>, id=13834, flags=<optimized out>, txn=0x34305c5533305c36, a=0x305c33315c36305c, 
    idl_disposition=0x3030315c31535532, buffer_handle=0x305c36305c65305c, type=<optimized out>) at ldap/servers/slapd/back-ldbm/index.c:1915
#5  0x305c39305c306230 in ?? ()
#6  0x34305c5533305c36 in ?? ()
#7  0x305c33315c36305c in ?? ()

Unfortunately, I don't have the full bt of thread 1 but we can see already where it's crashing.

there are NO encrypted attributes neither in RHDS9 nor in RHDS10.

We have asked to run with valgrind. We can see:

==2664== 1 errors in context 1 of 226:
==2664== Thread 87:
==2664== Invalid read of size 8
==2664==    at 0x7D9564D: _nl_locale_subfreeres (in /usr/lib64/libc-2.17.so)
==2664==    by 0x7D9548A: free_mem (in /usr/lib64/libc-2.17.so)
==2664==    by 0x7D95B71: __libc_freeres (in /usr/lib64/libc-2.17.so)
==2664==    by 0x4A24749: _vgnU_freeres (vg_preloaded.c:77)
==2664==    by 0x8E62BFFE: ???
==2664==    by 0x12BA3CAE: encode (in /usr/lib64/dirsrv/plugins/libback-ldbm.so)
==2664==    by 0x12BA5DC6: ??? (in /usr/lib64/dirsrv/plugins/libback-ldbm.so)
==2664==    by 0x305C39305C30622F: ???
==2664==    by 0x34305C5533305C35: ???
==2664==    by 0x305C33315C36305B: ???
==2664==    by 0x3030315C31535531: ???
==2664==    by 0x305C36305C65305B: ???
==2664==    by 0x61305C34305C5532: ???
==2664==    by 0x6E4537305C33315B: ???
==2664==    by 0x225C317473757273: ???

Version-Release number of selected component (if applicable): 389-ds-base-

How reproducible:  very often.

Comment 2 mreynolds 2017-10-05 20:23:31 UTC
Pretty sure this is fixed in 389-ds-base-

Comment 4 German Parente 2017-10-13 13:38:00 UTC
Created attachment 1338232 [details]
new valgrind output

Comment 10 German Parente 2017-10-24 15:34:56 UTC
Customer was using index by equality on binary attribute. Once that removed, the server has not crashed.

The bug is still valid.

Comment 11 mreynolds 2017-10-25 15:06:39 UTC

Comment 12 mreynolds 2017-10-25 15:19:45 UTC
I can not reproduce the issue with other binary attributes.  Can we get a copy of the exact binary attribute/value that is causing issues for the customer?

Comment 25 mreynolds 2017-11-06 12:05:00 UTC
Upstream ticket:

Comment 27 mreynolds 2017-11-07 15:07:28 UTC
Fixed upstream

Comment 30 Viktor Ashirov 2017-11-22 11:19:01 UTC
============================= test session starts ==============================
platform linux -- Python 3.6.3, pytest-3.2.5, py-1.5.2, pluggy-0.4.0 -- /opt/rh/rh-python36/root/usr/bin/python3
cachedir: .cache
metadata: {'Python': '3.6.3', 'Platform': 'Linux-3.10.0-768.el7.x86_64-x86_64-with-redhat-7.5-Maipo', 'Packages': {'pytest': '3.2.5', 'py': '1.5.2', 'pluggy': '0.4.0'}, 'Plugins': {'metadata': '1.5.0', 'html': '1.16.0'}}
nss: 3.34.0-0.1.beta1.el7
nspr: 4.17.0-1.el7
openldap: 2.4.44-9.el7
svrcore: 4.1.3-2.el7

rootdir: /export, inifile:
plugins: metadata-1.5.0, html-1.16.0
collected 1 item                                                                

tests/tickets/ticket49441_test.py::test_ticket49441 PASSED

========================== 1 passed in 10.23 seconds ===========================

Marking as VERIFIED.

Comment 33 errata-xmlrpc 2018-04-10 14:21:13 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.