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 923502 - Crash in MODRDN
Summary: Crash in MODRDN
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: 389-ds-base
Version: 6.4
Hardware: Unspecified
OS: Unspecified
urgent
high
Target Milestone: rc
: ---
Assignee: Rich Megginson
QA Contact: Sankar Ramalingam
URL:
Whiteboard:
Depends On:
Blocks: 929111
TreeView+ depends on / blocked
 
Reported: 2013-03-20 01:11 UTC by Nathan Kinder
Modified: 2020-09-13 20:25 UTC (History)
6 users (show)

Fixed In Version: 389-ds-base-1.2.11.15-14.el6_4
Doc Type: Bug Fix
Doc Text:
An out of scope problem for a local variable, in some cases, caused the modrdn operation to terminate unexpectedly with a segmentation fault. This update declares the local variable at the proper place of the function so it does not go out of scope, and the modrdn operation no longer crashes.
Clone Of:
Environment:
Last Closed: 2013-11-21 21:05:41 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 619 0 None None None 2020-09-13 20:25:39 UTC
Red Hat Product Errata RHBA-2013:1653 0 normal SHIPPED_LIVE 389-ds-base bug fix update 2013-11-20 21:53:19 UTC

Description Nathan Kinder 2013-03-20 01:11:45 UTC 
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/619

Version: main (march 12th 2013)
Testcase: run BOB acceptance tests...but it may be not systematic
Priority: major unless it appears to be a dynamic issue (less chance to occur)

backtrace:
(gdb) where
#0  __strlen_sse2_pminub () at ../sysdeps/x86_64/multiarch/strlen-sse2-pminub.S:39
#1  0x000000370ea1250b in cvt_s (flags=0, prec=<optimized out>, width=<optimized out>, str=<optimized out>, ss=0x7f053ffec8c0)
    at ../../../mozilla/nsprpub/pr/src/io/prprf.c:370
#2  dosprintf (ss=ss@entry=0x7f053ffec8c0, fmt=0x7f055f66e135 "", fmt@entry=0x7f055f66e130 "%s,%s", ap=ap@entry=0x7f053ffec918)
    at ../../../mozilla/nsprpub/pr/src/io/prprf.c:998
#3  0x000000370ea12868 in PR_vsmprintf (fmt=fmt@entry=0x7f055f66e130 "%s,%s", ap=ap@entry=0x7f053ffec918)
    at ../../../mozilla/nsprpub/pr/src/io/prprf.c:1145
#4  0x00007f05630f32d3 in slapi_create_dn_string (fmt=fmt@entry=0x7f055f66e130 "%s,%s") at ldap/servers/slapd/dn.c:1092
#5  0x00007f055f658ada in acl_modified (pb=<optimized out>, optype=<optimized out>, e_sdn=0x7f04e4000f20, change=0x7f053ffeca90)
    at ldap/servers/plugins/acl/acl.c:1801
#6  0x00007f0563136391 in plugin_call_acl_mods_update (pb=pb@entry=0x1b08a60, optype=optype@entry=64)
    at ldap/servers/slapd/plugin_acl.c:192
#7  0x00007f0563125e31 in op_shared_rename (pb=pb@entry=0x1b08a60, passin_args=0) at ldap/servers/slapd/modrdn.c:672
#8  0x00007f0563126534 in do_modrdn (pb=0x1b08a60) at ldap/servers/slapd/modrdn.c:268
#9  0x0000000000416c98 in connection_dispatch_operation (pb=<optimized out>, op=0x1b09530, conn=0x7f0551fb1e10)
    at ldap/servers/slapd/connection.c:588
#10 connection_threadmain () at ldap/servers/slapd/connection.c:2338
#11 0x000000370ea28cf3 in _pt_root (arg=0x1ac7b30) at ../../../mozilla/nsprpub/pr/src/pthreads/ptthread.c:156
#12 0x00000035d7007d14 in start_thread (arg=0x7f053ffef700) at pthread_create.c:309
#13 0x00000035d6cf168d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115


First analyze:
  The problem is that the set of changes provided to the acl_modified callback looks invalid. The pblock contains a valid newrdn but it is not clear for newsuperior or newsuperior_sdn.
   This bug is possibly related to bug fix https://fedorahosted.org/389/ticket/340
Comment 7 Amita Sharma 2013-04-03 11:50:39 UTC 
Hi Thierry,

I have tried it ::
================================================================================
[root@mgmt12 ~]# rpm -qa | grep 389
389-admin-console-doc-1.1.8-1.el6.noarch
389-ds-base-libs-1.2.11.15-12.el6_4.x86_64
389-admin-debuginfo-1.1.32-1.el6.x86_64
389-ds-console-1.2.7-1.el6.noarch
389-adminutil-devel-1.1.17-1.el6.x86_64
389-ds-base-1.2.11.15-12.el6_4.x86_64
389-adminutil-debuginfo-1.1.17-1.el6.x86_64
389-ds-base-devel-1.2.11.15-12.el6_4.x86_64
389-console-1.1.7-1.el6.noarch
389-admin-1.1.33-1.el6.x86_64
389-ds-base-debuginfo-1.2.11.15-12.el6_4.x86_64
389-admin-console-1.1.8-1.el6.noarch
389-ds-console-doc-1.2.7-1.el6.noarch
389-adminutil-1.1.17-1.el6.x86_64

[root@mgmt12 ~]# ldapadd -x -h localhost -p 389 -D "cn=Directory Manager" -w Secret123  << EOF
> dn: uid=testuser1,ou=people,dc=example,dc=com
> cn: ams
> sn: ams
> givenname: ams
> objectclass: top
> objectclass: person
> objectclass: organizationalPerson
> objectclass: inetOrgPerson
> uid: ams
> mail: ams
> userpassword: amsamsams
> EOF
adding new entry "uid=testuser1,ou=people,dc=example,dc=com"

[root@mgmt12 ~]# ldapmodify -x -h localhost -p 389 -D "cn=Directory Manager" -w Secret123  << EOF
> dn: uid=testuser1,ou=people,dc=example,dc=com
> changetype: modrdn
> newrdn: uid=testuser1changed
> deleteoldrdn: 1
> EOF
modifying rdn of entry "uid=testuser1,ou=people,dc=example,dc=com"

[root@mgmt12 ~]# ldapmodify -x -h localhost -p 389 -D "cn=Directory Manager" -w Secret123  << EOF
dn: uid=testuser1changed,ou=people,dc=example,dc=com
changetype: modrdn
newrdn: uid=testuser1       
deleteoldrdn: 1
EOF
modifying rdn of entry "uid=testuser1changed,ou=people,dc=example,dc=com"
================================================================================
But I could not reproduce the crash with old version of 389?
Can you please check if something I missed.

I also executed BOB tet suit with the above mentioned version of 389 but again could not reproduce. :(
Comment 11 Amita Sharma 2013-04-08 04:41:14 UTC 
Marking the bug Verified Sanity Only.
Comment 12 Sankar Ramalingam 2013-04-15 07:54:35 UTC 
Changing back to MODIFIED state since its a RHEL6.5 bug.
Comment 14 Sankar Ramalingam 2013-08-18 05:46:45 UTC 
Automated tests in mmrepl/fourwaymmr/fourwaymmr.sh. TET commits r7906 to r7907.
Comment 15 Sankar Ramalingam 2013-08-26 09:26:54 UTC 
Bug verified from automated tests for fourwaymmr.

fourwaymmr run Tests PASS      : 100% (24/24)

[bug923502] Instance M1 and M2 are still running after stressing with modrdn operations
Crash in ModRDN when running multiple threads of modrdn operations
TestCase [bug923502] result-> [PASS]
Comment 16 errata-xmlrpc 2013-11-21 21:05:41 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.

http://rhn.redhat.com/errata/RHBA-2013-1653.html
Note You need to log in before you can comment on or make changes to this bug.