(ITS#8526) Slapd dies when subjected to heavy load

[kwetlesen@mac.com]

Full_Name: Kai M Wetlesen
Version: 2.4.40
OS: RHEL 7.2 Maipo
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (198.4.83.52)


Hi All,

For some reason slapd crashes with a segmentation fault when subjected to a TLS
heavy connection load. It looks like the segmentation fault originates in
libnss3.so, but I cannot tell anything more than that.
AOAOct 28 11:48:57 ldap-primary.domain slapd[31842]: conn=2259 fd=26 closed
(TLS negotiation failure)
Oct 28 11:48:57 ldap-primary.domain slapd[31842]: conn=2260 fd=26 ACCEPT from
IP=XXX.XXX.205.98:49696 (IP=0.0.0.0:636)
(about 800 more lines like this)AOAOct 28 11:53:51 ldap-primary.domain
slapd[31842]: conn=2671 fd=33 ACCEPT from IP=XXX.XXX.205.98:60921
(IP=0.0.0.0:636)
Oct 28 11:53:51 ldap-primary.domain slapd[31842]: conn=2670 fd=34 closed (TLS
negotiation failure)
Oct 28 11:53:51 ldap-primary.domain slapd[31842]: conn=2672 fd=34 ACCEPT from
IP=XXX.XXX.205.98:60926 (IP=0.0.0.0:636)
Oct 28 11:53:51 ldap-primary.domain slapd[31842]: conn=2672 fd=34 closed (TLS
negotiation failure)
Oct 28 11:53:51 ldap-primary.domain kernel: slapd[32180]: segfault at 10 ip
00007f83554fcc65 sp 00007f83367fc550 error 4 in libnss3.so[7f83554b6000+11e000]
Oct 28 11:53:51 ldap-primary.domain systemd[1]: slapd.service: main process
exited, code=killed, status=11/SEGV

The traffic originates from a penetration test machine running Nessus which is
used where this server resides as part of a security sweep. Unfortunately I
don't have visibility as to what exact tests the Nessus server performs, but I
do know that the probes the server a couple hundred times to try and discover
what service is running. The machine is running on a lightly configured but
dedicated VM as this server was never expected to serve more than 400 clients.
Is this expected behavior?

Steps to reproduce:
- Install OpenLDAP
- Configure any DIT
- Configure OpenLDAP only to service ldaps:// using TLS
- Start the server
- Confgure Nessus scanner
- Run a Nessus vulnerability scan against the server

Thanks,
Kai Wetlesen