Bug 1303641 - heap corruption at schema replication.
heap corruption at schema replication.
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base (Show other bugs)
All Linux
urgent Severity urgent
: rc
: ---
Assigned To: Noriko Hosoi
Viktor Ashirov
Petr Bokoc
: ZStream
Depends On:
Blocks: 1368484 1335423
  Show dependency treegraph
Reported: 2016-02-01 09:49 EST by German Parente
Modified: 2016-11-03 16:39 EDT (History)
10 users (show)

See Also:
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
Story Points: ---
Clone Of:
: 1335423 1335685 (view as bug list)
Last Closed: 2016-11-03 16:39:10 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

  None (edit)
Description German Parente 2016-02-01 09:49:47 EST
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 18:48 EST
Created attachment 1120259 [details]
customer custom schema
Comment 15 Noriko Hosoi 2016-02-04 13:40:30 EST
Upstream ticket:
Comment 39 Rich Megginson 2016-02-17 16:51:02 EST
> 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 13:15 EDT
Created attachment 1141350 [details]
valgrind report
Comment 109 Sankar Ramalingam 2016-09-23 09:27:43 EDT
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 16:39:10 EDT
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.