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 1303641 - heap corruption at schema replication.
Summary: heap corruption at schema replication.
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.2
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
Petr Bokoc
Depends On:
Blocks: 1335423 1368484
TreeView+ depends on / blocked
Reported: 2016-02-01 14:49 UTC by German Parente
Modified: 2020-09-13 21:39 UTC (History)
10 users (show)

Fixed In Version: 389-ds-base-
Doc Type: Bug Fix
Doc Text:
Old schema styles can now correctly be used with single quotes Starting with version 1.3.2, the _389-ds-base_ packages are compliant with the schema definition described in RFC 4512, which does not allow the schema to be used by the older versions. To ease migration from previous versions, the `nsslapd-enquote-sup-oc` parameter was introduced. However, the implementation of this parameter had a bug which prevented handling old schema styles in single quotes, such as: SYNTAX oid This bug is now fixed, and you can use single quotes with older schema styles. Additionally, this update introduces the `LDAP_SCHEMA_ALLOW_QUOTES` environment variable which adds support for older style schema in the schema directory. To enable this functionality, set the following variable in the `/etc/sysconfig/dirsrv-INSTANCE` configuration file: LDAP_SCHEMA_ALLOW_QUOTED=on
Clone Of:
: 1335423 1335685 (view as bug list)
Last Closed: 2016-11-03 20:39:10 UTC
Target Upstream Version:

Attachments (Terms of Use)
customer custom schema (3.90 KB, application/x-gzip)
2016-02-01 23:48 UTC, German Parente
no flags Details
valgrind report (6.38 MB, text/plain)
2016-03-29 17:15 UTC, German Parente
no flags Details

System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 1774 0 None None None 2020-09-13 21:39:21 UTC
Red Hat Product Errata RHSA-2016:2594 0 normal SHIPPED_LIVE Moderate: 389-ds-base security, bug fix, and enhancement update 2016-11-03 12:11:08 UTC

Description German Parente 2016-02-01 14:49:47 UTC
Description of problem:

Seems that there's a corrupted syntaxinfo structure at replicating the schema 

Program terminated with signal 6, Aborted.
#0  0x00007f0ce3e3e5f7 in __GI_raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56	  return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);

(gdb) bt
#0  0x00007f0ce3e3e5f7 in __GI_raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007f0ce3e3fce8 in __GI_abort () at abort.c:90
#2  0x00007f0ce3e7e317 in __libc_message (do_abort=do_abort@entry=2, 
    fmt=fmt@entry=0x7f0ce3f879c8 "*** Error in `%s': %s: 0x%s ***\n")
    at ../sysdeps/unix/sysv/linux/libc_fatal.c:196
#3  0x00007f0ce3e85fe1 in malloc_printerr (
    ar_ptr=0x7f0ce41c3760 <main_arena>, ptr=<optimized out>, 
    str=0x7f0ce3f850b4 "free(): invalid pointer", action=3) at malloc.c:5013
#4  _int_free (av=0x7f0ce41c3760 <main_arena>, p=<optimized out>, 
    have_lock=0) at malloc.c:3835
#5  0x00007f0ce65fe9c6 in slapi_ch_free (ptr=0x7f0c80075b90)
    at ldap/servers/slapd/ch_malloc.c:292
#6  0x00007f0ce65fea35 in slapi_ch_free_string (s=<optimized out>)
    at ldap/servers/slapd/ch_malloc.c:325
#7  0x00007f0ce65f9608 in attr_syntax_free (a=0x7f0c80075b90)
    at ldap/servers/slapd/attrsyntax.c:195
#8  0x00007f0ce666b6ba in schema_berval_to_atlist (
    at ldap/servers/slapd/schema.c:7192
#9  0x00007f0ce666cea3 in schema_attributetypes_superset_check (
    type=type@entry=0x7f0cdb6f63e5 "supplier")
    at ldap/servers/slapd/schema.c:7267
#10 0x00007f0cdb6b28a7 in update_consumer_schema (
    at ldap/servers/plugins/replication/repl5_connection.c:1742
#11 0x00007f0cdb6b39a8 in conn_push_schema (conn=0x7f0ce86f6a30, 
    at ldap/servers/plugins/replication/repl5_connection.c:1823
#12 0x00007f0cdb6b5a77 in repl5_inc_run (prp=0x7f0ce86f9870)
    at ldap/servers/plugins/replication/repl5_inc_protocol.c:973
#13 0x00007f0cdb6bba3c in prot_thread_main (arg=0x7f0ce86a7230)
    at ldap/servers/plugins/replication/repl5_protocol.c:267
#14 0x00007f0ce48307bb in _pt_root (arg=0x7f0ce87037a0)
    at ../../../nspr/pr/src/pthreads/ptthread.c:212
#15 0x00007f0ce41d1dc5 in start_thread (arg=0x7f0c8f7fe700)
    at pthread_create.c:308
#16 0x00007f0ce3eff21d in clone ()

The problem seems to be when parsing the remote schema 

           rc = parse_at_str(at_berval[i]->bv_val, &at, errorbuf, sizeof (errorbuf),
                   DSE_SCHEMA_NO_CHECK | DSE_SCHEMA_USE_PRIV_SCHEMA, 0, schema_ds4x_compat, 0);

The structure at_berval seems to be right in the core:

(gdb) print at_berval[859]->bv_val
$28 = 0x7f0c80073950 "( 2.16.840.1.113730.3.1.612 NAME 'generation' DESC 'Netscape defined attribute type' SYNTAX '' X-ORIGIN 'Netscape Directory Server' )"
(gdb) print at_berval[859]
$29 = (struct berval *) 0x7f0c80073a00
(gdb) print at_berval[860]
$30 = (struct berval *) 0x0

so, it seems as if while parsing it to get the attribute sintaxis, something is not going on fine. 

Or the heap corruption could be former to that ?

I will try to give further details as possible.

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


Comment 6 German Parente 2016-02-01 23:48:39 UTC
Created attachment 1120259 [details]
customer custom schema

Comment 15 Noriko Hosoi 2016-02-04 18:40:30 UTC
Upstream ticket:

Comment 39 Rich Megginson 2016-02-17 21:51:02 UTC
> The value of DESC contains a non-ascii character.  According to the RFC, the value is supposed to be utf8, but it's not clear to me if it is a UTF8 string or not.

It is not utf8.  \341 is not a utf8 character.
(gdb) print (unsigned char)'\341'
$1 = 225 '\341'

The proper utf8 representation of this character should have 2 bytes.  Looks like this character is iso8859:

       341   225   E1     รก     LATIN SMALL LETTER A WITH ACUTE

This is usually the sort of thing that syntax checking catches.  For example, if attributetypes has DirectoryString syntax, this value should be rejected.  I don't know if we do syntax checking on schema values.

Comment 60 German Parente 2016-03-29 17:15:04 UTC
Created attachment 1141350 [details]
valgrind report

Comment 109 Sankar Ramalingam 2016-09-23 13:27:43 UTC
To reproduce crash with Custom schema replication.

1). Installed 389-ds-base- on RHEL7.3 latest RTT.

2). Created a working 2 Master and 2 Consumer replication setup.

3). Tested synchronization between Masters/Consumers.

4). Followed the steps given in comemnt #59 and #79 to reproduce the crash.

[root@ratangad slapd-M1]# ldapsearch -D "cn=Directory Manager" -w Secret123 -h localhost -p 1189 -x  -b "cn=config" |grep -i syntaxcheck
nsslapd-syntaxcheck: off

[root@ratangad slapd-M1]# ldapsearch -D "cn=Directory Manager" -w Secret123 -h localhost -p 1189 -x  -b "cn=config" |grep -i nsslapd-enquote-sup-oc
nsslapd-enquote-sup-oc: on

[root@ratangad slapd-M1]# cat /export/Backups/99deref_schema.ldif dn: cn=schema
attributeTypes: ( NAME 'testRunDerefUser' DESC 'Attribute DerefControl tests Multi-Valued' SYNTAX )
objectClasses: ( NAME 'testderefperson' SUP top STRUCTURAL MUST ( sn $ cn $ l $ testRunDerefUser )
        MAY ( userPassword $ seeAlso $ description ) X-ORIGIN 'DerefControlTest' )

[root@ratangad slapd-M1]# /usr/lib64/dirsrv/slapd-M1/stop-slapd  ; sleep 2 ; cp /export/Backups/99deref_schema.ldif /etc/dirsrv/slapd-M1/schema/

[root@ratangad slapd-M1]# /usr/lib64/dirsrv/slapd-M1/start-slapd  

[root@ratangad slapd-M1]# ./schema-reload.pl -v -Z slapd-M1 -D "cn=Directory Manager" -w Secret123 -d /etc/dirsrv/slapd-M1/schema/ldap_initialize( ldap://ratangad.eng.blr.redhat.com:1189 )
Successfully added task entry "cn=schema_reload_2016_9_23_18_16_37, cn=schema reload task, cn=tasks, cn=config"

[root@ratangad slapd-M1]# tail -f /var/log/dirsrv/slapd-M1/errors 
[23/Sep/2016:18:14:01.828640388 +051800] schemareload - Schema validation passed.
[23/Sep/2016:18:14:01.877523305 +051800] schemareload - Schema reload task finished.
[23/Sep/2016:18:16:37.041087640 +051800] schemareload - Schema reload task starts (schema dir: /etc/dirsrv/slapd-M1/schema/) ...
[23/Sep/2016:18:16:37.099379033 +051800] schemareload - Schema validation passed.
[23/Sep/2016:18:16:37.149524557 +051800] schemareload - Schema reload task finished.

5). Created/modified few entries in M1 to make the schema replicated to other masters and consumers.
[root@ratangad MMR_WINSYNC]# ./AddEntry.sh Users 1189 "ou=testing,dc=passsync,dc=com" derefusr 99 localhost > /dev/null
[root@ratangad MMR_WINSYNC]# PORT=1189; SUFF="dc=passsync,dc=com"; for PORT in `echo "1189 1289 1389 1489 "`; do /usr/bin/ldapsearch -x -p $PORT -h localhost -D "cn=Directory Manager" -w Secret123 -b $SUFF |grep -i dn: | wc -l ; done

[root@ratangad MMR_WINSYNC]# ldapmodify -D "cn=Directory Manager" -w Secret123 -h localhost -p 1189 -x  << EOFdn: uid=derefusr32,ou=Testing,dc=passsync,dc=com                                                                                             replace: userPassword
userPassword: Secret123

modifying entry "uid=derefusr32,ou=Testing,dc=passsync,dc=com"

[root@ratangad MMR_WINSYNC]# PORT=1389; SUFF="dc=passsync,dc=com"; PORT=1189 ;  /usr/bin/ldapsearch -x -p $PORT -h localhost -D "uid=derefusr32,ou=Testing,dc=passsync,dc=com" -w "abcdefhijklmnopqrstuvwxyzabcdefhijklmnopqrstuvwxyz" -b "uid=derefusr32,ou=Testing,dc=passsync,dc=com" > /dev/null ; echo $?
ldap_bind: Invalid credentials (49)
[root@ratangad MMR_WINSYNC]# PORT=1389; SUFF="dc=passsync,dc=com"; PORT=1189 ;  /usr/bin/ldapsearch -x -p $PORT -h localhost -D "uid=derefusr32,ou=Testing,dc=passsync,dc=com" -w "Secret123" -b "uid=derefusr32,ou=Testing,dc=passsync,dc=com" > /dev/null ; echo $?0
[root@ratangad MMR_WINSYNC]# PORT=1289; SUFF="dc=passsync,dc=com"; PORT=1189 ;  /usr/bin/ldapsearch -x -p $PORT -h localhost -D "uid=derefusr32,ou=Testing,dc=passsync,dc=com" -w "Secret123" -b "uid=derefusr32,ou=Testing,dc=passsync,dc=com" > /dev/null ; echo $?

6). [root@ratangad MMR_WINSYNC]# ls /var/spool/abrt
last-ccpp  last-via-server

No crashes observed. Also, no issues with syncing entries after schema replication. 

Hence, marking the bug as Verified.

[root@ratangad MMR_WINSYNC]# rpm -qa |grep -i 389-ds-base

Comment 111 errata-xmlrpc 2016-11-03 20:39:10 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.