RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1758473 - AddressSanitizer: heap-use-after-free in log_get_loglist
Summary: AddressSanitizer: heap-use-after-free in log_get_loglist
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: 389-ds-base
Version: 8.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.2
Assignee: mreynolds
QA Contact: RHDS QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-10-04 09:08 UTC by Viktor Ashirov
Modified: 2020-09-13 22:25 UTC (History)
6 users (show)

Fixed In Version: 389-ds-1.4-8020020200120164339.bf00efc9
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-28 16:01:22 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 3883 0 None closed AddressSanitizer: heap-use-after-free in log_get_loglist 2021-01-11 17:01:37 UTC
Red Hat Product Errata RHBA-2020:1703 0 None None None 2020-04-28 16:01:43 UTC

Description Viktor Ashirov 2019-10-04 09:08:27 UTC
Description of problem:

=================================================================
==4241==ERROR: AddressSanitizer: heap-use-after-free on address 0x6030003238c8 at pc 0x7f45b443389a bp 0x7f458d2e2a40 sp 0x7f458d2e2a30
READ of size 8 at 0x6030003238c8 thread T23
    #0 0x7f45b4433899 in log_get_loglist (/usr/lib64/dirsrv/libslapd.so.0+0x16a899)
    #1 0x7f45b441f16a in config_set_entry (/usr/lib64/dirsrv/libslapd.so.0+0x15616a)
    #2 0x7f45b43a9b68 in read_config_dse (/usr/lib64/dirsrv/libslapd.so.0+0xe0b68)
    #3 0x7f45b43c4f19  (/usr/lib64/dirsrv/libslapd.so.0+0xfbf19)
    #4 0x7f45b43c9181 in dse_search (/usr/lib64/dirsrv/libslapd.so.0+0x100181)
    #5 0x7f45b445c6ec in op_shared_search (/usr/lib64/dirsrv/libslapd.so.0+0x1936ec)
    #6 0x7f45b44921e9  (/usr/lib64/dirsrv/libslapd.so.0+0x1c91e9)
    #7 0x7f45b44928f6  (/usr/lib64/dirsrv/libslapd.so.0+0x1c98f6)
    #8 0x7f45b449315f in slapi_search_internal_get_entry (/usr/lib64/dirsrv/libslapd.so.0+0x1ca15f)
    #9 0x7f45b44aef6e in get_entry (/usr/lib64/dirsrv/libslapd.so.0+0x1e5f6e)
    #10 0x7f45b4446dd6  (/usr/lib64/dirsrv/libslapd.so.0+0x17ddd6)
    #11 0x7f45b444bc8b in do_modify (/usr/lib64/dirsrv/libslapd.so.0+0x182c8b)
    #12 0x556c81c64916  (/usr/sbin/ns-slapd+0x45916)
    #13 0x7f45b1c91567  (/lib64/libnspr4.so+0x2b567)
    #14 0x7f45b162c2dd in start_thread (/lib64/libpthread.so.0+0x82dd)
    #15 0x7f45b0e60132 in __GI___clone (/lib64/libc.so.6+0xfc132)

0x6030003238c8 is located 8 bytes inside of 24-byte region [0x6030003238c0,0x6030003238d8)
freed by thread T25 here:
    #0 0x7f45b4b3d720 in __interceptor_free (/lib64/libasan.so.5+0xef720)
    #1 0x7f45b43a5a8c in slapi_ch_free (/usr/lib64/dirsrv/libslapd.so.0+0xdca8c)
    #2 0x7f45b4432dd9 in log__delete_rotated_logs (/usr/lib64/dirsrv/libslapd.so.0+0x169dd9)
    #3 0x556c81c6ad2f  (/usr/sbin/ns-slapd+0x4bd2f)
    #4 0x7f45b1c91567  (/lib64/libnspr4.so+0x2b567)

previously allocated by thread T0 here:
    #0 0x7f45b4b3dae8 in __interceptor_malloc (/lib64/libasan.so.5+0xefae8)
    #1 0x7f45b43a5297 in slapi_ch_malloc (/usr/lib64/dirsrv/libslapd.so.0+0xdc297)
    #2 0x7f45b4432589 in access_log_openf (/usr/lib64/dirsrv/libslapd.so.0+0x169589)
    #3 0x7f45b4432b29 in log_update_accesslogdir (/usr/lib64/dirsrv/libslapd.so.0+0x169b29)
    #4 0x7f45b441105d in config_set_accesslog (/usr/lib64/dirsrv/libslapd.so.0+0x14805d)
    #5 0x7f45b441e847 in config_set (/usr/lib64/dirsrv/libslapd.so.0+0x155847)
    #6 0x7f45b43aa0af in load_config_dse (/usr/lib64/dirsrv/libslapd.so.0+0xe10af)
    #7 0x7f45b43c4f19  (/usr/lib64/dirsrv/libslapd.so.0+0xfbf19)
    #8 0x7f45b43c7f4e  (/usr/lib64/dirsrv/libslapd.so.0+0xfef4e)
    #9 0x7f45b43c85c1 in dse_read_file (/usr/lib64/dirsrv/libslapd.so.0+0xff5c1)
    #10 0x556c81c77f8b  (/usr/sbin/ns-slapd+0x58f8b)
    #11 0x556c81c4aec1  (/usr/sbin/ns-slapd+0x2bec1)
    #12 0x7f45b0d87872 in __libc_start_main (/lib64/libc.so.6+0x23872)

Thread T23 created by T0 here:
    #0 0x7f45b4aa0e73 in __interceptor_pthread_create (/lib64/libasan.so.5+0x52e73)
    #1 0x7f45b1c9123e  (/lib64/libnspr4.so+0x2b23e)

Thread T25 created by T0 here:
    #0 0x7f45b4aa0e73 in __interceptor_pthread_create (/lib64/libasan.so.5+0x52e73)
    #1 0x7f45b1c9123e  (/lib64/libnspr4.so+0x2b23e)

SUMMARY: AddressSanitizer: heap-use-after-free (/usr/lib64/dirsrv/libslapd.so.0+0x16a899) in log_get_loglist
Shadow bytes around the buggy address:
  0x0c068005c6c0: fd fa fa fa fd fd fd fa fa fa fd fd fd fa fa fa
  0x0c068005c6d0: fd fd fd fd fa fa fd fd fd fd fa fa fd fd fd fd
  0x0c068005c6e0: fa fa fd fd fd fd fa fa fd fd fd fd fa fa fd fd
  0x0c068005c6f0: fd fd fa fa fd fd fd fa fa fa fd fd fd fa fa fa
  0x0c068005c700: fd fd fd fd fa fa fd fd fd fa fa fa 00 00 00 06
=>0x0c068005c710: fa fa fd fd fd fa fa fa fd[fd]fd fa fa fa 00 00
  0x0c068005c720: 05 fa fa fa 00 00 05 fa fa fa 00 00 02 fa fa fa
  0x0c068005c730: 00 00 00 00 fa fa fd fd fd fd fa fa fd fd fd fd
  0x0c068005c740: fa fa fd fd fd fd fa fa fd fd fd fd fa fa fd fd
  0x0c068005c750: fd fa fa fa fd fd fd fd fa fa fd fd fd fa fa fa
  0x0c068005c760: fd fd fd fd fa fa fd fd fd fd fa fa fd fd fd fd
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
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  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
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==4241==ABORTING

Version-Release number of selected component (if applicable):
389-ds-base-1.4.1.3-7.module+el8.1.0+4150+5b8c2c1f.x86_64


How reproducible:
always

Steps to Reproduce:
1. Rebuild 389-ds-base with ASAN
2. Run tests/suites/disk_monitoring/disk_monitoring_test.py::test_operation_with_nsslapd_disk_monitoring_logging_critical_off_below_half_of_the_threshold	


Actual results:
ASAN reports heap-use-after-free

Expected results:
No errors from ASAN

Additional info:

Comment 2 mreynolds 2020-01-17 20:41:20 UTC
Upstream ticket

https://pagure.io/389-ds-base/issue/50829

Comment 4 Viktor Ashirov 2020-01-22 21:27:20 UTC
Build tested: 389-ds-base-1.4.2.4-6.2asan.el8.x86_64 (additionally contains https://pagure.io/389-ds-base/c/cf849cc to unblock tests)

Memory leaks are reported by the disk monitoring test suite:

=================================================================
==9128==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 24 byte(s) in 1 object(s) allocated from:
    #0 0x7fd43c0b2fb8 in __interceptor_realloc (/lib64/libasan.so.5+0xeffb8)
    #1 0x7fd43bb2d6ff in slapi_ch_realloc (/usr/lib64/dirsrv/libslapd.so.0+0xdb6ff)
    #2 0x7fd43bb2b6cf in slapi_ch_array_add_ext (/usr/lib64/dirsrv/libslapd.so.0+0xd96cf)
    #3 0x55e9f5e75420 in disk_mon_add_dir ldap/servers/slapd/daemon.c:258
    #4 0x55e9f5e7563d in disk_mon_get_dirs ldap/servers/slapd/daemon.c:285
    #5 0x55e9f5e760c9 in disk_monitoring_thread ldap/servers/slapd/daemon.c:453
    #6 0x7fd43941a567  (/lib64/libnspr4.so+0x2b567)

Indirect leak of 34 byte(s) in 1 object(s) allocated from:
    #0 0x7fd43bffed70 in strdup (/lib64/libasan.so.5+0x3bd70)
    #1 0x7fd43bb2d8fd in slapi_ch_strdup (/usr/lib64/dirsrv/libslapd.so.0+0xdb8fd)
    #2 0x55e9f5e75229 in disk_mon_get_mount_point ldap/servers/slapd/daemon.c:224
    #3 0x55e9f5e753a6 in disk_mon_add_dir ldap/servers/slapd/daemon.c:251
    #4 0x55e9f5e7563d in disk_mon_get_dirs ldap/servers/slapd/daemon.c:285
    #5 0x55e9f5e760c9 in disk_monitoring_thread ldap/servers/slapd/daemon.c:453
    #6 0x7fd43941a567  (/lib64/libnspr4.so+0x2b567)

Indirect leak of 2 byte(s) in 1 object(s) allocated from:
    #0 0x7fd43bffed70 in strdup (/lib64/libasan.so.5+0x3bd70)
    #1 0x7fd43bb2d8fd in slapi_ch_strdup (/usr/lib64/dirsrv/libslapd.so.0+0xdb8fd)
    #2 0x55e9f5e75229 in disk_mon_get_mount_point ldap/servers/slapd/daemon.c:224
    #3 0x55e9f5e753a6 in disk_mon_add_dir ldap/servers/slapd/daemon.c:251
    #4 0x55e9f5e755d0 in disk_mon_get_dirs ldap/servers/slapd/daemon.c:277
    #5 0x55e9f5e760c9 in disk_monitoring_thread ldap/servers/slapd/daemon.c:453
    #6 0x7fd43941a567  (/lib64/libnspr4.so+0x2b567)

SUMMARY: AddressSanitizer: 60 byte(s) leaked in 3 allocation(s).

Moving to ASSIGNED.

Comment 6 mreynolds 2020-01-23 19:58:19 UTC
The leaks you found are a different issue.  This bug addressed the heap-use-after-free issue.

Comment 7 Viktor Ashirov 2020-02-07 11:23:42 UTC
I filed a separate bug for memory leaks: https://bugzilla.redhat.com/show_bug.cgi?id=1800529

Moving this one to VERIFIED.

Comment 9 errata-xmlrpc 2020-04-28 16:01:22 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.

https://access.redhat.com/errata/RHBA-2020:1703


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