If a password is changed using the password modify extended operation, the modify used to modify the password will be leaked if the change is rejected due to password policy or access control settings.

To reproduce:

  - Set the following in cn=config:
  
    passwordStorageScheme: clear
    passwordCheckSyntax: on

  - Add the following test user:

    dn: uid=tuser,dc=example,dc=com
    objectclass: inetOrgPerson
    cn: Test User
    sn: User
    userPassword: simple

  - Use ldappasswd to attempt a password change with a bad password:

    ldappasswd -Y DIGEST-MD5 -U tuser -a Secret12 -s simple

The password change will be properly rejected as it doesn't meet the syntax requirements, but the mod will be leaked.  The memory leak can be seen if you run the test with valgrind:

==24500== 92 (16 direct, 76 indirect) bytes in 1 blocks are definitely lost in loss record 473 of 1,370
==24500==    at 0x4A05414: calloc (vg_replace_malloc.c:397)
==24500==    by 0x4C50859: slapi_ch_calloc (ch_malloc.c:243)
==24500==    by 0x4CC98D9: normalize_mods2bvals (util.c:360)
==24500==    by 0x4C8DD62: modify_internal_pb (modify.c:513)
==24500==    by 0x4C8DB95: slapi_modify_internal_pb (modify.c:443)
==24500==    by 0x422F90: passwd_apply_mods (passwd_extop.c:181)
==24500==    by 0x423158: passwd_modify_userpassword (passwd_extop.c:226)
==24500==    by 0x424407: passwd_modify_extop (passwd_extop.c:830)
==24500==    by 0x4C9C66E: plugin_call_exop_plugins (plugin.c:448)
==24500==    by 0x41B3BE: do_extended (extendop.c:376)
==24500==    by 0x4137B6: connection_dispatch_operation (connection.c:617)
==24500==    by 0x414D43: connection_threadmain (connection.c:2274)
==24500==    by 0x3896229772: (within /lib64/libnspr4.so)
==24500==    by 0x3E9EC06859: start_thread (in /lib64/libpthread-2.10.2.so)
==24500==    by 0x3E9E0DE22C: clone (in /lib64/libc-2.10.2.so)