Closed
Bug 550258
Opened 14 years ago
Closed 4 years ago
slot->mechanismList not protected from races in [@ PK11_ReadMechanismList]
Categories
(NSS :: Libraries, defect, P1)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
3.12.10
People
(Reporter: sg, Unassigned)
References
Details
(Keywords: crash)
Crash Data
Attachments
(1 file)
1.79 KB,
patch
|
nelson
:
review-
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.1.8) Gecko/20100202 Firefox/3.5.8 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.1.8) Gecko/20100202 Firefox/3.5.8 (.NET CLR 3.5.30729) I'm testing my smart card PKCS#11 module (osca.dll) and gor a crash in NSS. Directly after removing the smart card I connect to a https site. The crash occured in pk11slot.c line 1092. The dereference of mechanismList in the statement slot->mechanismList[i] was accessing a NULL pointer since a second thread was freeing and reallocating the mechanismList at the same time. Thread 1: Doing SSL authentication nss3.dll!PK11_ReadMechanismList - CRASH nss3.dll!PK11_InitToken nss3.dll!nssSlot_Refresh nss3.dll!nssSlot_IsTokenPresent nss3.dll!nssSlot_GetToken nss3.dll!nssTrustDomain_FindCertificatesBySubject nss3.dll!find_cert_issuer nss3.dll!nssCertificate_BuildChain nss3.dll!CERT_FindCertIssuer nss3.dll!cert_VerifyCertChainOld nss3.dll!cert_VerifyCertChain nss3.dll!CERT_VerifyCertChain nss3.dll!CERT_VerifyCert nss3.dll!CERT_VerifyCertNow ssl3.dll!SSL_AuthCertificate Thread 2: Normally doing C_WaitForSlotEvent osca.dll!C_GetMechanismList nss3.dll!PK11_ReadMechanismList nss3.dll!PK11_InitToken nss3.dll!nssSlot_Refresh nss3.dll!nssSlot_IsTokenPresent nss3.dll!nssToken_IsPresent nss3.dll!pk11_IsPresentCertLoad nss3.dll!PK11_IsPresent nspr4.dll!_PR_NativeRunThread I have browsed the NSS source code but have not found any lock protecting the PK11SlotInfo struct from simultanius access by two threads at the same time. Best Regards, Stefan Gustafsson Reproducible: Didn't try Steps to Reproduce: 1. Remove smart card triggering C_WaitForSlotEvent 2. At the same time connect to https site 3.
Severity: normal → critical
Keywords: crash
Summary: Crash in PK11_ReadMechanismList → Crash in [@ PK11_ReadMechanismList]
Assignee: nobody → timeless
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #481463 -
Flags: review?(nelson)
Updated•14 years ago
|
Target Milestone: --- → 3.12.10
Comment 2•14 years ago
|
||
Comment on attachment 481463 [details] [diff] [review] extend monitor This is not the right fix, IMO. More comments to follow.
Attachment #481463 -
Flags: review?(nelson) → review-
Comment 3•14 years ago
|
||
I agree that some mutual exclusion is needed here, but is now absent. I don't believe the "slot monitor" is the right one to use, especially not if conditionally called with "if (!slot->isThreadSafe)". AIUI, the slot monitor exists as a workaround for PKCS11 modules that lack their own internal mutual exclusion. It protects the data that is private to that module by effectively single-threading all calls to the module's PKCS#11 API functions. It does not exist to protect the PK11wrap layer's own slot structure, which is presumed to be thread safe. Now, we see an apparent bug in the PK11wrap layer's own exclusion of access to its own slot structure. This flaw exists for both PKCS#11 modules that ' are thought to be threadsafe, and those that are not, alike, so it's not appropriate to devise a solution that only works for modules with their own thread safety issues. Bob, please advise about the right solution for this. Is there another lock or monitor that exists to provide this mutual exclusion? Clearly the slot struct's reference counter is insufficient for this purpose.
Priority: -- → P1
Summary: Crash in [@ PK11_ReadMechanismList] → slot->mechanismList not protected from races in [@ PK11_ReadMechanismList]
Version: unspecified → 3.12
Updated•13 years ago
|
Crash Signature: [@ PK11_ReadMechanismList]
Hi, We're still experiencing the same problem with SSL client authentication by smartcard when using Firefox 18.0.2, the browser crashes, even in safe mode. Is there anybody at Mozilla who can deal with this issue which has been open since 2010? For us, this issue is highly critical because it occurs systematically. Regards.
Comment 6•11 years ago
|
||
The race looks like it's more of a race between nss_slotRefresh calls. I suspect there is more than mechanism lists that could cause an issue...
Comment 7•4 years ago
|
||
Closing because no crashes reported for 12 weeks.
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•