Bug 1073313 - (CVE-2017-17740) VUL-0: CVE-2017-17740: openldap2: contrib/slapd-modules/nops/nops.c, when both the nops module and the memberof overlay are enabled, attempts to free a buffer that was allocated on the stack
(CVE-2017-17740)
VUL-0: CVE-2017-17740: openldap2: contrib/slapd-modules/nops/nops.c, when bot...
Status: RESOLVED FIXED
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
unspecified
Other Other
: P3 - Medium : Normal
: ---
Assigned To: The 'Opening Windows to a Wider World' guys
Security Team bot
https://smash.suse.de/issue/196828/
CVSSv3:RedHat:CVE-2017-17740:5.9:(AV:...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2017-12-18 13:34 UTC by Marcus Meissner
Modified: 2020-01-31 15:40 UTC (History)
13 users (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
patch for fix the original free and additional patch to allow nop & memberof to both work together (10.89 KB, application/mbox)
2018-12-19 16:50 UTC, Noel Power
Details
patch for fix the original free and additional patch to allow nop & memberof to both work together (version2) (11.17 KB, application/mbox)
2018-12-19 18:10 UTC, Noel Power
Details
patch for fix the original free and additional patch to allow nop & memberof to both work together (version3) (11.60 KB, application/mbox)
2018-12-20 12:30 UTC, Noel Power
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marcus Meissner 2017-12-18 13:34:51 UTC
CVE-2017-17740

contrib/slapd-modules/nops/nops.c in OpenLDAP through 2.4.45, when both the nops
module and the memberof overlay are enabled, attempts to free a buffer that was
allocated on the stack, which allows remote attackers to cause a denial of
service (slapd crash) via a member MODDN operation.

References:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-17740
http://www.openldap.org/its/index.cgi/Incoming?id=8759
Comment 1 Marcus Meissner 2017-12-18 13:43:17 UTC
http://www.openldap.org/its/index.cgi/Incoming?id=8759



if we enable overlay nops & memberof together, then doing a member MODDN
operation, slapd will segfault and exit immediately.

Example operation:

dn: uid=test,ou=People,dc=example,dc=dc=com
changetype: moddn
newrdn: uid=chenln
deleteoldrdn: 1
newsuperior: ou=Leave,dc=example,dc=com

The reason is: in servers/slapd/overlays/memberof.c, function
memberof_value_modify define mod/values/nvalues in the stack, which will be
passed to other overlays, nops will try to free them if no attribute is changed.
Comment 2 Marcus Meissner 2017-12-18 13:43:45 UTC
second comment from above url decoded:
# more /etc/openldap/slapd.conf
include        /etc/openldap/schema/core.schema
include        /etc/openldap/schema/cosine.schema
include        /etc/openldap/schema/inetorgperson.schema
include        /etc/openldap/schema/rfc2307bis.schema

pidfile        /run/openldap/slapd.pid
argsfile       /run/openldap/slapd.args

moduleload     memberof.so
moduleload     nops-overlay.so

database       hdb
suffix         "o=demo,c=cn"
rootdn         "cn=root,o=demo,c=cn"
rootpw         "123456"
directory      /var/lib/openldap-data/

overlay memberof
memberof-group-oc groupOfMembers
memberof-refint   true

overlay nops

# more /tmp/1.ldif
dn: o=demo,c=cn
o: demo
objectClass: organization
structuralObjectClass: organization

dn: ou=Group,o=demo,c=cn
objectClass: organizationalUnit
ou: Group

dn: ou=People,o=demo,c=cn
objectClass: organizationalUnit
ou: People

dn: ou=Leave,o=demo,c=cn
objectClass: organizationalUnit
ou: Leave

dn: uid=liuzx,ou=People,o=demo,c=cn
gidNumber: 20000
objectClass: posixAccount
objectClass: inetOrgPerson
structuralObjectClass: inetOrgPerson
uidNumber: 10000
uid: liuzx
homeDirectory: /home/users/liuzx
sn: Liu
cn: Z. Liu
memberOf: cn=users,ou=Group,o=demo,c=cn
mobile: 13910823475

dn: cn=users,ou=Group,o=demo,c=cn
objectClass: groupOfMembers
cn: users
member: uid=liuzx,ou=People,o=demo,c=cn

# sudo -u ldap slapadd -l 1.ldif
# service slapd start
# ps | grep slapd # confirm slapd is running
# more ~/t.ldif
dn: uid=liuzx,ou=People,o=demo,c=cn
changetype: moddn
newrdn: uid=liuzx
deleteoldrdn: 1
newsuperior: ou=Leave,o=demo,c=cn

# ldapmodify -H ldap://127.0.0.1 -D 'cn=root,o=demo,c=cn' -w 123456  -f t.ldif
modifying rdn of entry "uid=liuzx,ou=People,o=demo,c=cn"
ldap_result: Can't contact LDAP server (-1)

# ps | grep slapd # confirm slapd is gone

sometimes dmesg can see kernel log:
traps: slapd[25560] general protection ip:7fabf60b0e72 sp:7fabd969bfd0 error:0 in libc-2.23.so[7fabf6068000+19f000]
slapd[26437]: segfault at 737265626d81 ip 00000000004aa4d0 sp 00007f63c2c79710 error 4 in slapd[400000+15a000]
Comment 3 Johannes Segitz 2018-03-02 13:30:27 UTC
Please submit for this. Thanks
Comment 5 Chris Kowalczyk 2018-09-10 12:53:16 UTC
Hello Peter and Johannes,

I moved the variables from stack to heap, as it was advised in the CVE analysis. This seems to build fine and, as far as I was able to look at the code, it should work okay for the two features mentioned in this bug:

https://build.opensuse.org/project/show/home:ckowalczyk:branches:network:ldap:bsc1073313

However, I haven't tested it in real environment.
Comment 6 Johannes Segitz 2018-09-12 07:15:02 UTC
(In reply to Chris Kowalczyk from comment #5)
I had a quick look. This looks good, but if new_ndn is not null then ml is free'd and still used if old_ndn is also not null later on. I don't know enough about the context to know if this can happen, but this should be checked
Comment 7 Chris Kowalczyk 2018-09-19 08:48:18 UTC
(In reply to Johannes Segitz from comment #6)
> (In reply to Chris Kowalczyk from comment #5)
> I had a quick look. This looks good, but if new_ndn is not null then ml is
> free'd and still used if old_ndn is also not null later on. I don't know
> enough about the context to know if this can happen, but this should be
> checked

Do you mean, ml is deleted in line 455 ("slap_mods_free( ml, 1 );")?
After that, in line 468 a new variable is assigned to ml: ("ml = &mod[ mcnt ];"), so I guess it could be used afterwards.

I added the freeing of those values (mod, values, nvalues) at the end of the function, so this shouldn't change anything in the main flow of the function.

But of course, I agree, it would be good to reproduce this environment and test this thoroughly.
Comment 18 Swamp Workflow Management 2018-12-17 11:12:51 UTC
SUSE-SU-2018:4150-1: An update that fixes one vulnerability is now available.

Category: security (moderate)
Bug References: 1073313
CVE References: CVE-2017-17740
Sources used:
SUSE Linux Enterprise Software Development Kit 12-SP4 (src):    openldap2-2.4.41-18.43.1
SUSE Linux Enterprise Software Development Kit 12-SP3 (src):    openldap2-2.4.41-18.43.1
SUSE Linux Enterprise Server 12-SP4 (src):    openldap2-2.4.41-18.43.1
SUSE Linux Enterprise Server 12-SP3 (src):    openldap2-2.4.41-18.43.1
SUSE Linux Enterprise Desktop 12-SP4 (src):    openldap2-2.4.41-18.43.1
SUSE Linux Enterprise Desktop 12-SP3 (src):    openldap2-2.4.41-18.43.1
SUSE CaaS Platform ALL (src):    openldap2-2.4.41-18.43.1
SUSE CaaS Platform 3.0 (src):    openldap2-2.4.41-18.43.1
OpenStack Cloud Magnum Orchestration 7 (src):    openldap2-2.4.41-18.43.1
Comment 26 Noel Power 2019-02-26 14:25:10 UTC
I tried to dig deeper but it is the details of memberof and what it is trying to achieve (and how) that is stumping me. However here is a brain dump of things learnt from looking at the code and/or any documentation I could find. Also at the end my own conclusion


Some background info about the problem and the overlays involved and what they do.


What does the memberof overlay do

    + memberof overlay according to the man page

        "allows automatic reverse group membership maintenance.  Any time a group entry is modified, its members are modified as appropriate in order to keep a DN-valued "is member of" attribute updated with the DN of the group"


What does the nops overlay do

    + From the code "For each attribute modification, check if the modification and the old entry are the same, if they are remove the modification"

      Also nops doesn't check 'LDAP_MOD_REPLACE' modifications, these are ignored

What is the problem ?

    + The nops overlay detects a nop modification and removes it, in this case the the nop modification is on the stack. Now there are actually 2 problems
        a) The previous patch to fix the stack problem converted the stack modifications object(s) to heap based ones. However, the patch isn't correctly implemented and causes some new memory errors
        b) Even if these memory errors were not a problem there are some asserts in the code that will be triggered if a modification is removed (maybe indicating that a nop shouldn't be generated by memberof anyway)




Where does it start to go pear shaped ...?

the following is a call stack (with modified nops code to abort for the purposes of debugging, so... the line numbers won't quite line up with the orig source) The assert below is raised just before the problematice attempt to delete the stack based modifcation.

#0  0x00007faa984bb0e0 in raise () from /lib64/libc.so.6
#1  0x00007faa984bc6c1 in abort () from /lib64/libc.so.6
#2  0x00007faa984b36fa in __assert_fail_base () from /lib64/libc.so.6
#3  0x00007faa984b3772 in __assert_fail () from /lib64/libc.so.6
#4  0x00007faa95bc5ebc in nops_rm_mod (mod=0x7faa952d5df0, mods=0x7faa952d5fa8) at nops.c:61
#5  nops_modify (op=0x7faa952d5f60, rs=0x7faa952d5d80) at nops.c:143
#6  0x0000000000496bc5 in overlay_op_walk ()
#7  0x0000000000496d1a in ?? ()
#8  0x00007faa95dca8e4 in memberof_value_modify (op=op@entry=0x7faa88002c90, ndn=<optimized out>, ad=0xaf8f10, old_dn=old_dn@entry=0x7faa88002cb8, old_ndn=old_ndn@entry=0x7faa88002cc8, new_dn=new_dn@entry=0x7faa952d6160, new_ndn=0x7faa952d6180) at memberof.c:426
#9  0x00007faa95dcb1dd in memberof_res_modrdn (op=0x7faa88002c90, rs=<optimized out>) at memberof.c:1593
#10 0x000000000043f088 in ?? ()
#11 0x000000000043f557 in ?? ()
#12 0x000000000043fe7a in slap_send_ldap_result ()
#13 0x00007faa95fe3d04 in hdb_modrdn (op=0x7faa88002c90, rs=0x7faa952d6aa0) at modrdn.c:793
#14 0x0000000000496bfb in overlay_op_walk ()
#15 0x0000000000496d1a in ?? ()
#16 0x0000000000448a39 in fe_op_modrdn ()
#17 0x0000000000449ad5 in do_modrdn ()
#18 0x000000000043049c in ?? ()
#19 0x00000000004307fa in ?? ()
#20 0x00007faa9a5f9c4a in ldap_int_thread_pool_wrapper (xpool=0x959f70) at tpool.c:696
#21 0x00007faa98846559 in start_thread () from /lib64/libpthread.so.0
#22 0x00007faa9857d81f in clone () from /lib64/libc.so.6


'memberof_res_modrdn' is a response callback that adds/deletes member values when a group member is renamed. I guess that this means this response callback happens after the orig update is processed by the database (meaning that changes to the db already happened ??).

That callback is setup from memberof_op_modrdn,  which is itself is one of the overlay operations

                if ( rc == LDAP_SUCCESS ) {
                        for ( i = 0; !BER_BVISNULL( &vals[ i ] ); i++ ) {
==>                             memberof_value_modify( op,
                                                &vals[ i ], mo->mo_ad_member,
                                                &op->o_req_dn, &op->o_req_ndn,
                                                &newDN, &newNDN );

memberof_value_modify ends up calling out to the handler to call other 'stacked' modules 'bi_op_modify' operations eventually hitting the 'nops_modify' operation. However before this it sets up the 'stack' Modifications in question

(gdb) print vals
$4 = (BerVarray) 0x7efdbc003b60
(gdb) print vals[0]
$5 = {bv_len = 29, bv_val = 0x7efdbc003b88 "cn=users,ou=group,o=demo,c=cn"}
(gdb) print vals[1]
$6 = {bv_len = 0, bv_val = 0x0}
(gdb) print op->o_req_dn
$7 = {bv_len = 31, bv_val = 0x7efdbc003548 "uid=liuzx,ou=People,o=demo,c=cn"}
(gdb) print newDN
$8 = {bv_len = 30, bv_val = 0x7efdbc003ad0 "uid=liuzx,ou=Leave,o=demo,c=cn"}
(gdb) print newNDN
$9 = {bv_len = 30, bv_val = 0x7efdbc003aa8 "uid=liuzx,ou=leave,o=demo,c=cn"}
(gdb) print op->o_req_ndn
$10 = {bv_len = 31, bv_val = 0x7efdbc0035d8 "uid=liuzx,ou=people,o=demo,c=cn"}
(gdb) 
(gdb) print *mo->mo_ad_member
$21 = {ad_next = 0x0, ad_type = 0x1b6a680, ad_cname = {bv_len = 6, bv_val = 0x1b6a5f0 "member"}, ad_tags = {bv_len = 0, bv_val = 0x0}, ad_flags = 0, ad_index = 181}

which gets translated into the 2 Modifications that are sent to nops (via stacker overlay module operations)

(gdb) print mod[0]
$11 = {sml_mod = {sm_desc = 0x1b16d20, sm_values = 0x7efdca61ad00, sm_nvalues = 0x7efdca61ad40, sm_numvals = 1, sm_op = 2, sm_flags = 1, sm_type = {bv_len = 13, bv_val = 0x1b39180 "modifiersName"}}, sml_next = 0x0}j
print mod[0].sm_values[0]

(gdb) print mod[1]
$12 = {sml_mod = {sm_desc = 0x1ce3140, sm_values = 0x7efdca61ad20, sm_nvalues = 0x7efdca61ad60, sm_numvals = 1, sm_op = 0, sm_flags = 1, sm_type = {bv_len = 6, bv_val = 0x1b6a5f0 "member"}}, sml_next = 0x0}


(gdb) print &mod[0]
$13 = (Modifications *) 0x7efdca61adf0
(gdb) print &mod[1]
$14 = (Modifications *) 0x7efdca61ae28
(gdb) 

note both sml_next are NULL (this is because the debug is after nops removed (0x7efdca61adf0) aka mod[0])

mod[1]->sml_next would have pointed to &mod[0]

(gdb) print mod[0].sml_mod.sm_values
$15 = (BerVarray) 0x7efdca61ad00
(gdb) print mod[0].sml_mod.sm_values[0]
$16 = {bv_len = 19, bv_val = 0x1ce3180 "cn=root,o=demo,c=cn"}
(gdb) print mod[0].sml_mod.sm_values[1]
$17 = {bv_len = 0, bv_val = 0x0}
(gdb) print mod[1].sml_mod.sm_values[0]
$18 = {bv_len = 30, bv_val = 0x7efdbc003ad0 "uid=liuzx,ou=Leave,o=demo,c=cn"}
(gdb) print mod[1].sml_mod.sm_values[1]
$19 = {bv_len = 0, bv_val = 0x0}


The problematic Modifications (from the point of view of nops.c) is the one associate with attribute "member" above

other bits

   + So, nops determines the LDAP_MOD_ADD Modifcations (the one with sm_op = 0) to have no changes against the old attribute (therefore a nop). So either
      a) this is incorrect, and as it is written at the moment the code clearly determines that it *is* a nop. Maybe the check for 'nop' isn't deterministic enough, I don't know enough about this to tell.
      b) memberof is incorrectly creating a nop change (but that kindof brings us back to the purpose of the nops overlay... which is to remove such changes anyway)
  + what about the other contrib modules, do these use stack or heap based Modifications

addpartial/addpartial-overlay.c calls be_modify with heap Modifications
autogroup/autgroup.c seems to call be_modify with both heap and stack Modifications :
    LDAP_MOD_ADD (heap)
    LDAP_MOD_ADD (stack)
    LDAP_MOD_DELETE (heap)
lastbind/lastbind.c calls be_modify with heap Modifications
nssov/pam.c calls be_modify with STACK Modifications (could be with LDAP_MOD_DELETE or LDAP_MOD_ADD)
samba4/pguid.c calls be_modify with heap Modifications
samba4/rdnval.c calls  be_modify with heap Modifications
samba4/vernum.c calls  be_modify with STACK Modifications (with LDAP_MOD_REPLACE) so that is ok


   + what about the official overlays

accesslog.c calls  be_modify with STACK Modifications (with LDAP_MOD_REPLACE) so that is ok
dds.c calls be_modify with STACK Modifications (with LDAP_MOD_REPLACE) so that is ok
memberof.c unfortunately we know this calls be_modify with STACK Modifications (with LDAP_MOD_ADD or LDB_MOD_DELETE)
pcache.c:
    calls be_modify with heap Modifications  (LDAP_MOD_ADD)
    calls be_modify with STACK Modifications (LDAP_MOD_DELETE)
    calls be_modify with STACK Modifications (LDAP_MOD_REPLACE) so that one doesn't matter
    calls be_modify with heap Modifications  
    calls be_modify with STACK Modifications (LDAP_MOD_DELETE)
    calls be_modify with STACK Modifications (LDAP_MOD_REPLACE) so that one doesn't matter
ppolicy.c:
    calls be_modify with heap Modifications
refint.c
    calls be_modify with heap Modifications (LDAP_MOD_ADD, LDAP_MOD_DELETE, LDAP_MOD_REPLACE)
syncprov.c
    calls be_modify with STACK Modifications (LDAP_MOD_REPLACE) so that one doesn't matter

Looking at the modules above it seems Modifications sent down the line to stacked overlays are not gauranteed to be stack or heap, therefore afaics there is no way for an overlay to know whether it should delete that those modifications or not.

Conclusion

Given all of the above I think safest course is to use my 0001 patch above (instead of the chris's patch for same, e.g. replace patch 0017 in the obs build). This will protect against the stack deletions in this scenario. Note: this doesn't address either
   a) the issue of the asserts which will still fire
   b) whether there is a bug in nops.c
   c) whether there is a bug in membersof.c that produces a bogus modification

but these are all pre-existing issues and I think could be deferred 'till someone more clueful can look deeper, perhaps my second patch is helpful there (or not). In any case despite the asserts getting triggered at the very least we do need to fix the memory issues introduced by Chris's fix by either replacing or removing the problematic patch. Would be great to get a second/third opinion on it all
Comment 27 William Brown 2019-02-26 23:37:57 UTC
Thanks for this write up! This is a great analysis of the problem. 

From my view there are two "larger" contributing components to the problem. The first is the stack vs heap confusion. With any data that is passed through functions in this way, it's always safer to use heap to make sure it can be "freed anywhere", to prevent issues like this. But I think it's well beyond scope of this issue to rewrite openldap to do this.

The second is the nop plugin itself. Reading your analysis, it seems like this is premature optimitisation which violates the "correct, simple, fast" rule. By trying to make the modifications "fast" by nopping redundant changes, it has violated correctness which is that memberOf can just make a stateful assertion "this value should exist", which the other parts of the backend can just enforce and apply itself. I can only imagine this would cause some headaches with replication perhaps too. 

Perhaps an option is to disable compilation of the nops module, since upstream has made it pretty clear they don't intend to support this code - leaving it in an odd limbo state. 

Just some other ideas for the problem, but otherwise, great work on these patches and this write up :)
Comment 28 James McDonough 2019-03-27 18:24:31 UTC
I'm a bit confused, because I can't find the nops module anywhere that we ship, and it's completely unsupported by upstream.
Comment 32 Marcus Meissner 2019-04-10 15:56:59 UTC
On SLE15, the module is in openldap2-contrib package, which is not shipped.

-> not affected there
Comment 33 Marcus Meissner 2019-04-10 16:00:11 UTC
The nops module is not built on SLES 12.

=> not affected.
Comment 34 Thomas Abraham 2019-04-10 18:36:46 UTC
(In reply to Marcus Meissner from comment #33)
> The nops module is not built on SLES 12.
> 
> => not affected.

Can we update the CVE page to reflect this?
Comment 36 Michael Ströder 2019-04-19 15:04:36 UTC
While I'm well-known to use almost every OpenLDAP overlay available there is no good use-case for unmaintained slapo-nops.

=> I'd recommend to disable building it and remove it from package openldap2-contrib simply because I would expect more subtle issues (e.g. with delta-syncrepl).
Comment 37 Marcelo Martins 2019-04-26 12:48:26 UTC
I am testing update S:M:9510:190827 on SLES 15, and verify that slapd still hangs after applied update:

From my lab:
sles15-kvm:/etc/openldap # sudo -u ldap slapadd -l 1.ldif
_#################### 100.00% eta   none elapsed            none fast!
Closing DB...

sles15-kvm:/etc/openldap # systemctl start slapd

sles15-kvm:/etc/openldap # ps aux | grep -i slapd
ldap      5292  0.0  0.2 130836  9600 ?        Ssl  15:54   0:00 /usr/sbin/slapd -h ldap:///  ldapi:/// -f /etc/openldap/slapd.conf -u ldap -g ldap -o slp=off 
root      5295  0.0  0.0   8688   992 pts/1    R+   15:55   0:00 grep --color=auto -i slapd

sles15-kvm:/etc/openldap # ldapmodify -H ldap://127.0.0.1 -D 'cn=root,o=demo,c=cn' -w 123456  -f t.ldif
modifying rdn of entry "uid=liuzx,ou=People,o=demo,c=cn"
ldap_result: Can't contact LDAP server (-1)

sles15-kvm:/etc/openldap # ps aux | grep -i slapd
root      5304  0.0  0.0   8688   836 pts/1    S+   15:55   0:00 grep --color=auto -i slapd

sles15-kvm:/etc/openldap # systemctl status slapd
● slapd.service - OpenLDAP Server Daemon
   Loaded: loaded (/usr/lib/systemd/system/slapd.service; disabled; vendor preset: disabled)
   Active: failed (Result: signal) since Thu 2019-04-25 15:55:25 -03; 4min 9s ago
  Process: 5248 ExecStart=/usr/lib/openldap/start (code=exited, status=0/SUCCESS)
 Main PID: 5292 (code=killed, signal=ABRT)

Apr 25 15:54:57 sles15-kvm systemd[1]: Started OpenLDAP Server Daemon. 
Apr 25 15:55:24 sles15-kvm slapd[5292]: conn=1000 fd=11 ACCEPT from IP=127.0.0.1:45552 (IP=0.0.0.0:389)
Apr 25 15:55:24 sles15-kvm slapd[5292]: conn=1000 op=0 BIND dn="cn=root,o=demo,c=cn" method=128
Apr 25 15:55:24 sles15-kvm slapd[5292]: conn=1000 op=0 BIND dn="cn=root,o=demo,c=cn" mech=SIMPLE ssf=0
Apr 25 15:55:24 sles15-kvm slapd[5292]: conn=1000 op=0 RESULT tag=97 err=0 text=
Apr 25 15:55:24 sles15-kvm slapd[5292]: connection_input: conn=1000 deferring operation: binding 
Apr 25 15:55:24 sles15-kvm slapd[5292]: conn=1000 op=1 MODRDN dn="uid=liuzx,ou=People,o=demo,c=cn"
Apr 25 15:55:25 sles15-kvm systemd[1]: slapd.service: Main process exited, code=killed, status=6/ABRT
Apr 25 15:55:25 sles15-kvm systemd[1]: slapd.service: Unit entered failed state.
Apr 25 15:55:25 sles15-kvm systemd[1]: slapd.service: Failed with result 'signal'.


I observed that if I restart the slpad, hangs doesn't occurs more:

sles15-kvm:/etc/openldap # systemctl start slapd

sles15-kvm:/etc/openldap # ps aux | grep -i slapd
ldap     15075  0.1  0.2 130836  9368 ?        Ssl  09:46   0:00 /usr/sbin/slapd -h ldap:///  ldapi:/// -f /etc/openldap/slapd.conf -u ldap -g ldap -o slp=off
root     15079  0.0  0.0   8688   988 pts/0    S+   09:46   0:00 grep --color=auto -i slapd

sles15-kvm:/etc/openldap # ldapmodify -H ldap://127.0.0.1 -D 'cn=root,o=demo,c=cn' -w 123456  -f t.ldif
modifying rdn of entry "uid=liuzx,ou=People,o=demo,c=cn"
ldap_rename: No such object (32)
        matched DN: ou=People,o=demo,c=cn

sles15-kvm:/etc/openldap # ps aux | grep -i slapd
ldap     15075  0.0  0.2 343836 11416 ?        Ssl  09:46   0:00 /usr/sbin/slapd -h ldap:///  ldapi:/// -f /etc/openldap/slapd.conf -u ldap -g ldap -o slp=off
root     15084  0.0  0.0   8688   920 pts/0    S+   09:46   0:00 grep --color=auto -i slapd
Comment 38 Marcelo Martins 2019-04-26 12:49:20 UTC
I am testing update S:M:9510:190827 on SLES 15, and verify that slapd still hangs after applied update:

From my lab:
sles15-kvm:/etc/openldap # sudo -u ldap slapadd -l 1.ldif
_#################### 100.00% eta   none elapsed            none fast!
Closing DB...

sles15-kvm:/etc/openldap # systemctl start slapd

sles15-kvm:/etc/openldap # ps aux | grep -i slapd
ldap      5292  0.0  0.2 130836  9600 ?        Ssl  15:54   0:00 /usr/sbin/slapd -h ldap:///  ldapi:/// -f /etc/openldap/slapd.conf -u ldap -g ldap -o slp=off 
root      5295  0.0  0.0   8688   992 pts/1    R+   15:55   0:00 grep --color=auto -i slapd

sles15-kvm:/etc/openldap # ldapmodify -H ldap://127.0.0.1 -D 'cn=root,o=demo,c=cn' -w 123456  -f t.ldif
modifying rdn of entry "uid=liuzx,ou=People,o=demo,c=cn"
ldap_result: Can't contact LDAP server (-1)

sles15-kvm:/etc/openldap # ps aux | grep -i slapd
root      5304  0.0  0.0   8688   836 pts/1    S+   15:55   0:00 grep --color=auto -i slapd

sles15-kvm:/etc/openldap # systemctl status slapd
● slapd.service - OpenLDAP Server Daemon
   Loaded: loaded (/usr/lib/systemd/system/slapd.service; disabled; vendor preset: disabled)
   Active: failed (Result: signal) since Thu 2019-04-25 15:55:25 -03; 4min 9s ago
  Process: 5248 ExecStart=/usr/lib/openldap/start (code=exited, status=0/SUCCESS)
 Main PID: 5292 (code=killed, signal=ABRT)

Apr 25 15:54:57 sles15-kvm systemd[1]: Started OpenLDAP Server Daemon. 
Apr 25 15:55:24 sles15-kvm slapd[5292]: conn=1000 fd=11 ACCEPT from IP=127.0.0.1:45552 (IP=0.0.0.0:389)
Apr 25 15:55:24 sles15-kvm slapd[5292]: conn=1000 op=0 BIND dn="cn=root,o=demo,c=cn" method=128
Apr 25 15:55:24 sles15-kvm slapd[5292]: conn=1000 op=0 BIND dn="cn=root,o=demo,c=cn" mech=SIMPLE ssf=0
Apr 25 15:55:24 sles15-kvm slapd[5292]: conn=1000 op=0 RESULT tag=97 err=0 text=
Apr 25 15:55:24 sles15-kvm slapd[5292]: connection_input: conn=1000 deferring operation: binding 
Apr 25 15:55:24 sles15-kvm slapd[5292]: conn=1000 op=1 MODRDN dn="uid=liuzx,ou=People,o=demo,c=cn"
Apr 25 15:55:25 sles15-kvm systemd[1]: slapd.service: Main process exited, code=killed, status=6/ABRT
Apr 25 15:55:25 sles15-kvm systemd[1]: slapd.service: Unit entered failed state.
Apr 25 15:55:25 sles15-kvm systemd[1]: slapd.service: Failed with result 'signal'.


I observed that if I restart the slpad, hangs doesn't occurs more:

sles15-kvm:/etc/openldap # systemctl start slapd

sles15-kvm:/etc/openldap # ps aux | grep -i slapd
ldap     15075  0.1  0.2 130836  9368 ?        Ssl  09:46   0:00 /usr/sbin/slapd -h ldap:///  ldapi:/// -f /etc/openldap/slapd.conf -u ldap -g ldap -o slp=off
root     15079  0.0  0.0   8688   988 pts/0    S+   09:46   0:00 grep --color=auto -i slapd

sles15-kvm:/etc/openldap # ldapmodify -H ldap://127.0.0.1 -D 'cn=root,o=demo,c=cn' -w 123456  -f t.ldif
modifying rdn of entry "uid=liuzx,ou=People,o=demo,c=cn"
ldap_rename: No such object (32)
        matched DN: ou=People,o=demo,c=cn

sles15-kvm:/etc/openldap # ps aux | grep -i slapd
ldap     15075  0.0  0.2 343836 11416 ?        Ssl  09:46   0:00 /usr/sbin/slapd -h ldap:///  ldapi:/// -f /etc/openldap/slapd.conf -u ldap -g ldap -o slp=off
root     15084  0.0  0.0   8688   920 pts/0    S+   09:46   0:00 grep --color=auto -i slapd
Comment 39 Michael Ströder 2019-04-26 13:14:57 UTC
(In reply to Marcelo Martins from comment #38)
> sles15-kvm:/etc/openldap # ldapmodify -H ldap://127.0.0.1 -D
> 'cn=root,o=demo,c=cn' -w 123456  -f t.ldif
> modifying rdn of entry "uid=liuzx,ou=People,o=demo,c=cn"
> ldap_result: Can't contact LDAP server (-1)

That sounds to me there's still a seg fault happening.

Did you really reset to the start state when conducting the 2nd test?

> sles15-kvm:/etc/openldap # ldapmodify -H ldap://127.0.0.1 -D
> 'cn=root,o=demo,c=cn' -w 123456  -f t.ldif
> modifying rdn of entry "uid=liuzx,ou=People,o=demo,c=cn"
> ldap_rename: No such object (32)
>         matched DN: ou=People,o=demo,c=cn

It seems to me that some modification in t.ldif sent before was successful and therefore the entry was already renamed. So this 2nd test does not count as a real test result.
Comment 40 Marcelo Martins 2019-04-26 14:34:10 UTC
(In reply to Michael Ströder from comment #39)
> (In reply to Marcelo Martins from comment #38)
> > sles15-kvm:/etc/openldap # ldapmodify -H ldap://127.0.0.1 -D
> > 'cn=root,o=demo,c=cn' -w 123456  -f t.ldif
> > modifying rdn of entry "uid=liuzx,ou=People,o=demo,c=cn"
> > ldap_result: Can't contact LDAP server (-1)
> 
> That sounds to me there's still a seg fault happening.
> 
> Did you really reset to the start state when conducting the 2nd test?

Yes, I clear configurations, install update, certify stop slapd and tested again.
> 
> > sles15-kvm:/etc/openldap # ldapmodify -H ldap://127.0.0.1 -D
> > 'cn=root,o=demo,c=cn' -w 123456  -f t.ldif
> > modifying rdn of entry "uid=liuzx,ou=People,o=demo,c=cn"
> > ldap_rename: No such object (32)
> >         matched DN: ou=People,o=demo,c=cn
> 
> It seems to me that some modification in t.ldif sent before was successful
> and therefore the entry was already renamed. So this 2nd test does not count
> as a real test result.

hummm, ok, I really not sure about this, It has been clarified now. Thanks.
Comment 41 Noel Power 2019-05-01 08:15:51 UTC
(In reply to Marcelo Martins from comment #38)
> I am testing update S:M:9510:190827 on SLES 15, and verify that slapd still
> hangs after applied update:
> 
> From my lab:
> sles15-kvm:/etc/openldap # sudo -u ldap slapadd -l 1.ldif
> _#################### 100.00% eta   none elapsed            none fast!
> Closing DB...
> 
> sles15-kvm:/etc/openldap # systemctl start slapd
> 
> sles15-kvm:/etc/openldap # ps aux | grep -i slapd
> ldap      5292  0.0  0.2 130836  9600 ?        Ssl  15:54   0:00
> /usr/sbin/slapd -h ldap:///  ldapi:/// -f /etc/openldap/slapd.conf -u ldap
> -g ldap -o slp=off 
> root      5295  0.0  0.0   8688   992 pts/1    R+   15:55   0:00 grep
> --color=auto -i slapd
> 
> sles15-kvm:/etc/openldap # ldapmodify -H ldap://127.0.0.1 -D
> 'cn=root,o=demo,c=cn' -w 123456  -f t.ldif
> modifying rdn of entry "uid=liuzx,ou=People,o=demo,c=cn"
> ldap_result: Can't contact LDAP server (-1)
> 
> sles15-kvm:/etc/openldap # ps aux | grep -i slapd
> root      5304  0.0  0.0   8688   836 pts/1    S+   15:55   0:00 grep
> --color=auto -i slapd
> 
> sles15-kvm:/etc/openldap # systemctl status slapd
> ● slapd.service - OpenLDAP Server Daemon
>    Loaded: loaded (/usr/lib/systemd/system/slapd.service; disabled; vendor
> preset: disabled)
>    Active: failed (Result: signal) since Thu 2019-04-25 15:55:25 -03; 4min
> 9s ago
>   Process: 5248 ExecStart=/usr/lib/openldap/start (code=exited,
> status=0/SUCCESS)
>  Main PID: 5292 (code=killed, signal=ABRT)
> 
> Apr 25 15:54:57 sles15-kvm systemd[1]: Started OpenLDAP Server Daemon. 
> Apr 25 15:55:24 sles15-kvm slapd[5292]: conn=1000 fd=11 ACCEPT from
> IP=127.0.0.1:45552 (IP=0.0.0.0:389)
> Apr 25 15:55:24 sles15-kvm slapd[5292]: conn=1000 op=0 BIND
> dn="cn=root,o=demo,c=cn" method=128
> Apr 25 15:55:24 sles15-kvm slapd[5292]: conn=1000 op=0 BIND
> dn="cn=root,o=demo,c=cn" mech=SIMPLE ssf=0
> Apr 25 15:55:24 sles15-kvm slapd[5292]: conn=1000 op=0 RESULT tag=97 err=0
> text=
> Apr 25 15:55:24 sles15-kvm slapd[5292]: connection_input: conn=1000
> deferring operation: binding 
> Apr 25 15:55:24 sles15-kvm slapd[5292]: conn=1000 op=1 MODRDN
> dn="uid=liuzx,ou=People,o=demo,c=cn"
> Apr 25 15:55:25 sles15-kvm systemd[1]: slapd.service: Main process exited,
> code=killed, status=6/ABRT
> Apr 25 15:55:25 sles15-kvm systemd[1]: slapd.service: Unit entered failed
> state.
> Apr 25 15:55:25 sles15-kvm systemd[1]: slapd.service: Failed with result
> 'signal'.
> 
> 
> I observed that if I restart the slpad, hangs doesn't occurs more:
> 
> sles15-kvm:/etc/openldap # systemctl start slapd
> 
> sles15-kvm:/etc/openldap # ps aux | grep -i slapd
> ldap     15075  0.1  0.2 130836  9368 ?        Ssl  09:46   0:00
> /usr/sbin/slapd -h ldap:///  ldapi:/// -f /etc/openldap/slapd.conf -u ldap
> -g ldap -o slp=off
> root     15079  0.0  0.0   8688   988 pts/0    S+   09:46   0:00 grep
> --color=auto -i slapd
> 
> sles15-kvm:/etc/openldap # ldapmodify -H ldap://127.0.0.1 -D
> 'cn=root,o=demo,c=cn' -w 123456  -f t.ldif
> modifying rdn of entry "uid=liuzx,ou=People,o=demo,c=cn"
> ldap_rename: No such object (32)
>         matched DN: ou=People,o=demo,c=cn
> 
> sles15-kvm:/etc/openldap # ps aux | grep -i slapd
> ldap     15075  0.0  0.2 343836 11416 ?        Ssl  09:46   0:00
> /usr/sbin/slapd -h ldap:///  ldapi:/// -f /etc/openldap/slapd.conf -u ldap
> -g ldap -o slp=off
> root     15084  0.0  0.0   8688   920 pts/0    S+   09:46   0:00 grep
> --color=auto -i slapd

is this still with nops enabled (and openldap2-contrib installed) ?
note: openldap2-contrib is not supported (nor I believed shipped or at least I couldn't find it) comment #32 comment #33 comment #34
Comment 43 Swamp Workflow Management 2019-05-21 06:17:37 UTC
SUSE-SU-2019:0931-1: An update that solves two vulnerabilities and has three fixes is now available.

Category: security (important)
Bug References: 1031702,1037396,1041764,1065083,1073313
CVE References: CVE-2017-17740,CVE-2017-9287
Sources used:
SUSE Linux Enterprise Server for SAP 12-SP4 (src):    openldap2-2.4.41-18.24.9.7
SUSE Linux Enterprise Server for SAP 12-SP3 (src):    openldap2-2.4.41-18.24.9.7
SUSE Linux Enterprise Server for SAP 12-SP2 (src):    openldap2-2.4.41-18.24.9.7
SUSE Linux Enterprise Server for SAP 12-SP1 (src):    openldap2-2.4.41-18.24.9.7, openldap2-client-2.4.41-18.24.9.1
SUSE Linux Enterprise Server for SAP 12 (src):    openldap2-2.4.41-18.24.9.7, openldap2-client-2.4.41-18.24.9.1
SUSE Linux Enterprise Server 12-SP1-LTSS (src):    openldap2-2.4.41-18.24.9.7, openldap2-client-2.4.41-18.24.9.1
SUSE Linux Enterprise Server 12-LTSS (src):    openldap2-2.4.41-18.24.9.7, openldap2-client-2.4.41-18.24.9.1
SUSE Linux Enterprise Module for Legacy Software 12 (src):    openldap2-2.4.41-18.24.9.7

*** NOTE: This information is not intended to be used for external
    communication, because this may only be a partial fix.
    If you have questions please reach out to maintenance coordination.
Comment 45 Swamp Workflow Management 2019-07-25 13:40:07 UTC
This is an autogenerated message for OBS integration:
This bug (1073313) was mentioned in
https://build.opensuse.org/request/show/718552 Factory / openldap2
Comment 49 Swamp Workflow Management 2019-09-18 10:11:10 UTC
SUSE-SU-2019:2395-1: An update that solves three vulnerabilities and has two fixes is now available.

Category: security (moderate)
Bug References: 1073313,1111388,1114845,1143194,1143273
CVE References: CVE-2017-17740,CVE-2019-13057,CVE-2019-13565
Sources used:
SUSE Linux Enterprise Module for Open Buildservice Development Tools 15-SP1 (src):    openldap2-2.4.46-9.19.2
SUSE Linux Enterprise Module for Open Buildservice Development Tools 15 (src):    openldap2-2.4.46-9.19.2
SUSE Linux Enterprise Module for Legacy Software 15-SP1 (src):    openldap2-2.4.46-9.19.2
SUSE Linux Enterprise Module for Legacy Software 15 (src):    openldap2-2.4.46-9.19.2
SUSE Linux Enterprise Module for Development Tools 15-SP1 (src):    openldap2-2.4.46-9.19.2
SUSE Linux Enterprise Module for Development Tools 15 (src):    openldap2-2.4.46-9.19.2
SUSE Linux Enterprise Module for Basesystem 15-SP1 (src):    openldap2-2.4.46-9.19.2
SUSE Linux Enterprise Module for Basesystem 15 (src):    openldap2-2.4.46-9.19.2

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
Comment 50 Swamp Workflow Management 2019-09-23 22:10:54 UTC
openSUSE-SU-2019:2157-1: An update that solves three vulnerabilities and has two fixes is now available.

Category: security (moderate)
Bug References: 1073313,1111388,1114845,1143194,1143273
CVE References: CVE-2017-17740,CVE-2019-13057,CVE-2019-13565
Sources used:
openSUSE Leap 15.1 (src):    openldap2-2.4.46-lp151.10.3.1
Comment 51 Swamp Workflow Management 2019-09-24 13:15:02 UTC
openSUSE-SU-2019:2176-1: An update that solves three vulnerabilities and has two fixes is now available.

Category: security (moderate)
Bug References: 1073313,1111388,1114845,1143194,1143273
CVE References: CVE-2017-17740,CVE-2019-13057,CVE-2019-13565
Sources used:
openSUSE Leap 15.0 (src):    openldap2-2.4.46-lp150.13.1
Comment 52 Marcus Meissner 2020-01-31 15:40:06 UTC
released