389-ds-base

#48282 ns-slapd crashes with TLS/SSL requests on Xen VMs
Closed: wontfix Opened by immauss.

Closed: wontfix
Reopen Issue

I have a client with 389-ds on CentOS 6.7 running in a smallish network. It provides auth for local Linux machines, a few routers and a VPN server. I run a monthly security assessment using Openvas, and this month, the scan caused the directory server to crash. ns-slapd dies. I've gone through the scanning config for Openvas, and the only thing that causes the crash is port scans. I've not been able to reproduce this on another server, however when we cloned the machine, the crash was reproducible on the clone. (This may be a limit of my abilities.) I've verified the md5 sums (using rpm -V) for ds-389 and all of its dependencies. I'm attaching the stacktrace, core and a sosreport, if there is anything else I can add that will help isolate the issue, please let me know.

Compressed core file
core.6681.xz

Stacktrace from core file
stacktrace.1442425363.txt.xz

Try setting NSS_DISABLE_HW_GCM=1 in the environment e.g. in /etc/sysconfig/dirsrv-instancename

Hello immauss,

Any feedback to the suggestion in comment:1?

Hi rmeggins,
Just got time to test today but no, it still crashed on me.

This is a problem with Xen and NSS - see https://bugzilla.redhat.com/show_bug.cgi?id=1257332

The problem is most noticeable with 389 because 389 is one of the few servers that uses NSS for TLS/SSL.

So, let's leave this ticket open for now, with a link to the bz which explains the problem in great detail along with workarounds. We can close this ticket when there is a new NSS softokn release that contains the fix.

rmeggins,
Thanks! 

    Is there a publicly available list of the workarounds? I get an "Access Denied" when I try that BZ.

-Scott

Hello immauss,
If it still crashes with "NSS_DISABLE_HW_GCM=1" in /etc/sysconfig/dirsrv-YOUR_SERVER_INSTANCE, could you add this environment variable, too?
NSS_DISABLE_HW_AES=1

nhosoi,
That did the trick. Fully tested against each probe that previously crashed the server and no issues.

Thanks!!

Replying to [comment:8 immauss]:

nhosoi,
That did the trick. Fully tested against each probe that previously crashed the server and no issues.

Thanks!!
Glad to hear that. Thanks for your input!

Metadata Update from @rmeggins:
- Issue set to the milestone: 1.3.5 backlog

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1613

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Invalid)
Metadata
None
None
None
None
Normal
no review needed
Community
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.