#49491 collation subtring match with final pattern looks broken
Closed: wontfix 6 years ago Opened 6 years ago by tbordaz.

Issue Description

The problem arise with ASAN.
It reveals an access overflow.

Now trying to fix it, the matching of collation substring looks broken when using a final pattern.

Package Version and Platform

Any version

Steps to reproduce

  1. Create an instance running with ASAN
  2. Creates an entry to retrieve like
    dn: cn=user10,ou=People,dc=example,dc=com
    objectClass: top
    objectClass: person
    objectClass: inetuser
    objectClass: userSecurityInformation
    sn: _user10
    description: added on MUX
    cn: user10

  3. Run a search

    ldapsearch -LLL -o ldif-wrap=no -D "cn=directory manager" -W -b "dc=example,dc=com" '(description:2.16.840.1.113730.3.3.2.1.1.6:=*MUX)'

Actual results

It exits with

=================================================================
==8376==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000b7a08f at pc 0x7f1ea5a88156 bp 0x7f1e66c34fe0 sp 0x7f1e66c34fd0
READ of size 1 at 0x603000b7a08f thread T44
    #0 0x7f1ea5a88155 in SetUnicodeStringFromUTF_8 389-ds-base/ldap/servers/plugins/collation/collate.c:259
    #1 0x7f1ea5a887b9 in collation_index 389-ds-base/ldap/servers/plugins/collation/collate.c:313
    #2 0x7f1ea5a8bbbd in ss_filter_match 389-ds-base/ldap/servers/plugins/collation/orfilter.c:196
    #3 0x7f1ea5a8c4da in or_filter_match 389-ds-base/ldap/servers/plugins/collation/orfilter.c:286
    #4 0x7f1ead675751 in test_extensible_filter 389-ds-base/ldap/servers/slapd/filterentry.c:521
    #5 0x7f1ead676d1d in slapi_vattr_filter_test_ext_internal 389-ds-base/ldap/servers/slapd/filterentry.c:879
    #6 0x7f1ead6773cb in vattr_test_filter_list_or 389-ds-base/ldap/servers/slapd/filterentry.c:1036
    #7 0x7f1ead676e15 in slapi_vattr_filter_test_ext_internal 389-ds-base/ldap/servers/slapd/filterentry.c:891
    #8 0x7f1ead67652e in slapi_vattr_filter_test_ext 389-ds-base/ldap/servers/slapd/filterentry.c:771
    #9 0x7f1ead676447 in slapi_vattr_filter_test 389-ds-base/ldap/servers/slapd/filterentry.c:715
    #10 0x7f1e9fcb6e39 in ldbm_back_next_search_entry_ext 389-ds-base/ldap/servers/slapd/back-ldbm/ldbm_search.c:1650
    #11 0x7f1e9fcb57e0 in ldbm_back_next_search_entry 389-ds-base/ldap/servers/slapd/back-ldbm/ldbm_search.c:1326
    #12 0x7f1ead6d87ff in iterate 389-ds-base/ldap/servers/slapd/opshared.c:1221
    #13 0x7f1ead6d9c3c in send_results_ext 389-ds-base/ldap/servers/slapd/opshared.c:1611
    #14 0x7f1ead6d76c6 in op_shared_search 389-ds-base/ldap/servers/slapd/opshared.c:811
    #15 0x458793 in do_search 389-ds-base/ldap/servers/slapd/search.c:332
    #16 0x41d1d1 in connection_dispatch_operation 389-ds-base/ldap/servers/slapd/connection.c:648
    #17 0x422053 in connection_threadmain 389-ds-base/ldap/servers/slapd/connection.c:1760
    #18 0x7f1eab38068a  (/lib64/libnspr4.so+0x2968a)
    #19 0x7f1eaad1c619 in start_thread (/lib64/libpthread.so.0+0x7619)
    #20 0x7f1eaa80d5fc in clone (/lib64/libc.so.6+0x1025fc)

0x603000b7a08f is located 1 bytes to the left of 32-byte region [0x603000b7a090,0x603000b7a0b0)
allocated by thread T44 here:
    #0 0x7f1eadd6897a in malloc (/lib64/libasan.so.2+0x9897a)
    #1 0x7f1ead627759 in slapi_ch_malloc 389-ds-base/ldap/servers/slapd/ch_malloc.c:95
    #2 0x7f1ead79ebf8 in value_new 389-ds-base/ldap/servers/slapd/value.c:157
    #3 0x7f1ead79eb10 in slapi_value_dup 389-ds-base/ldap/servers/slapd/value.c:147
    #4 0x7f1ead7a68b2 in slapi_valueset_add_attr_valuearray_ext 389-ds-base/ldap/servers/slapd/valueset.c:1147
    #5 0x7f1ead7a4e69 in slapi_valueset_add_valuearray 389-ds-base/ldap/servers/slapd/valueset.c:862
    #6 0x7f1ead6162b5 in attrlist_merge_valuearray 389-ds-base/ldap/servers/slapd/attrlist.c:100
    #7 0x7f1ead657c0e in slapi_entry_attr_merge_sv 389-ds-base/ldap/servers/slapd/entry.c:2568
    #8 0x7f1ead657b73 in slapi_entry_attr_merge 389-ds-base/ldap/servers/slapd/entry.c:2560
    #9 0x7f1ead657e83 in slapi_entry_attr_replace 389-ds-base/ldap/servers/slapd/entry.c:2647
    #10 0x7f1ead6599b2 in slapi_entry_attr_set_charptr 389-ds-base/ldap/servers/slapd/entry.c:2892
    #11 0x7f1e9fc2635d in id2entry 389-ds-base/ldap/servers/slapd/back-ldbm/id2entry.c:419
    #12 0x7f1e9fcb67f1 in ldbm_back_next_search_entry_ext 389-ds-base/ldap/servers/slapd/back-ldbm/ldbm_search.c:1543
    #13 0x7f1e9fcb57e0 in ldbm_back_next_search_entry 389-ds-base/ldap/servers/slapd/back-ldbm/ldbm_search.c:1326
    #14 0x7f1ead6d87ff in iterate 389-ds-base/ldap/servers/slapd/opshared.c:1221
    #15 0x7f1ead6d9c3c in send_results_ext 389-ds-base/ldap/servers/slapd/opshared.c:1611
    #16 0x7f1ead6d76c6 in op_shared_search 389-ds-base/ldap/servers/slapd/opshared.c:811
    #17 0x458793 in do_search 389-ds-base/ldap/servers/slapd/search.c:332
    #18 0x41d1d1 in connection_dispatch_operation 389-ds-base/ldap/servers/slapd/connection.c:648
    #19 0x422053 in connection_threadmain 389-ds-base/ldap/servers/slapd/connection.c:1760
    #20 0x7f1eab38068a  (/lib64/libnspr4.so+0x2968a)

Thread T44 created by T0 here:
    #0 0x7f1eadd06673 in pthread_create (/lib64/libasan.so.2+0x36673)
    #1 0x7f1eab380372  (/lib64/libnspr4.so+0x29372)

SUMMARY: AddressSanitizer: heap-buffer-overflow 389-ds-base/ldap/servers/plugins/collation/collate.c:259 SetUnicodeStringFromUTF_8
Shadow bytes around the buggy address:
  0x0c06801673c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c06801673d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c06801673e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c06801673f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0680167400: fa fa fa fa fa fa fa fa fa fa fa fa 00 00 00 00
=>0x0c0680167410: fa[fa]00 00 00 00 fa fa fd fd fd fd fa fa 00 00
  0x0c0680167420: 00 00 fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa
  0x0c0680167430: 00 00 00 00 fa fa 00 00 00 00 fa fa 00 00 00 00
  0x0c0680167440: fa fa 00 00 00 00 fa fa fd fd fd fd fa fa 00 00
  0x0c0680167450: 00 00 fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa
  0x0c0680167460: 00 00 00 00 fa fa 00 00 03 fa fa fa 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
==8376==ABORTING

Expected results

It should not exit and should also return the user10 entry


you say:

Package Version and Platform
Any version

but Viktor said it is a regression, so there should be a working version

Metadata Update from @lkrispen:
- Custom field component adjusted to None
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None
- Custom field type adjusted to None
- Custom field version adjusted to None

6 years ago

Actually https://pagure.io/389-ds-base/issue/49471 was hiding #49491.

I made a patch for #49491, then playing with various substring match I hit #49491.
Unfortunately this last one is much more complex to fix. I suspect the matching of collation substring with final pattern to be broken and with a far too complex implementation.

I suspect #49491 to not return the matching entries and to exit in ASAN.

Metadata Update from @mreynolds:
- Issue set to the milestone: 1.3.7.0

6 years ago

Closing this bug as duplicate of #49545
The ticket #49491 was a ASAN assert that actually reveal a real bug (inconsistent result #49545 ).
Fixing #49545 also fix #49491.

Metadata Update from @tbordaz:
- Issue assigned to tbordaz

6 years ago

Metadata Update from @tbordaz:
- Issue close_status updated to: duplicate
- Issue status updated to: Closed (was: Open)

6 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/2550

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)

3 years ago

Login to comment on this ticket.

Metadata