Bug 784672 - nss should protect against being called before nss_Init
Summary: nss should protect against being called before nss_Init
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: nss
Version: 15
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Elio Maldonado Batiz
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 771734 (view as bug list)
Depends On:
Blocks: 784674 784676
TreeView+ depends on / blocked
 
Reported: 2012-01-25 19:10 UTC by Rich Megginson
Modified: 2012-02-08 02:26 UTC (History)
4 users (show)

Fixed In Version: nss-3.13.1-11.fc16
Clone Of:
: 784674 (view as bug list)
Environment:
Last Closed: 2012-02-04 05:32:53 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Patch: make sure the initLock has been initialized in every case we use it. (1.78 KB, patch)
2012-01-25 19:55 UTC, Bob Relyea
no flags Details | Diff

Description Rich Megginson 2012-01-25 19:10:10 UTC
beginning with nss 3.13 there is code like this:

SECStatus
NSS_RegisterShutdown(NSS_ShutdownFunc sFunc, void *appData)
{
    int i;

    PZ_Lock(nssInitLock);

The problem is that nssInitLock is NULL until nss_Init() is called, PZ_Lock will crash if called with NULL, and there are some poorly written applications that may call NSS_RegisterShutdown() and other functions before calling nss_Init().

Comment 1 Rich Megginson 2012-01-25 19:44:43 UTC
This causes crashes admin server in Red Hat Directory Server/389 because of mod_nss https://bugzilla.redhat.com/show_bug.cgi?id=618466 because mod_nss calls SSL_ClearSessionCache() during shutdown without checking to see if NSS_IsInitialized() is true.

I can see where there is a chicken/egg problem here
    PZ_Lock(nssInitLock);
    if (!NSS_IsInitialized()) {

you have to acquire the nssInitLock to make sure nssIsInitted isn't changed out from under you, but nssInitLock is NULL if nssIsInitted is 0.

So one way to guard against using NULL nssInitLock would be to call:
    /* make sure our lock and condition variable are initialized one and only
     * one time */ 
    if (PR_CallOnce(&nssInitOnce, nss_doLockInit) != PR_SUCCESS) {
	return SECFailure;
    }

before the first attempt to use nssInitLock in any function that uses nssInitLock.  That might be too heavyweight.

another approach would be to use an atomic integer for nssIsInitted.  NSPR provides pratom.h.  That way you could be guaranteed that all accesses of nssIsInitted would be implicitly protected.

The best approach would be to use static lock initialization like
 static pthread_mutex_t nssInitLock = PTHREAD_MUTEX_INITIALIZER;
but I do not think NSPR has support for static PR_Lock initialization.

Comment 2 Bob Relyea 2012-01-25 19:55:08 UTC
Created attachment 557512 [details]
Patch: make sure the initLock has been initialized in every case we use it.

Comment 3 Fedora Update System 2012-01-31 16:14:13 UTC
nss-3.13.1-11.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/nss-3.13.1-11.fc16

Comment 4 Fedora Update System 2012-01-31 16:15:18 UTC
nss-3.13.1-11.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/nss-3.13.1-11.fc15

Comment 5 Fedora Update System 2012-01-31 21:57:57 UTC
Package nss-3.13.1-11.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing nss-3.13.1-11.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-1064/nss-3.13.1-11.fc16
then log in and leave karma (feedback).

Comment 6 Fedora Update System 2012-02-04 05:32:53 UTC
nss-3.13.1-11.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 7 Nathan Kinder 2012-02-07 19:10:45 UTC
*** Bug 771734 has been marked as a duplicate of this bug. ***

Comment 8 Fedora Update System 2012-02-08 02:26:31 UTC
nss-3.13.1-11.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.