1308857 - Firefox freeze after choose a certificate when more than one security device (PKCS#11) is loaded.

Status: RESOLVED WORKSFORME

(NSS :: Libraries, defect)

Description

[dessy.vutova]

Attachment: pkcs11s.zip

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161006105459

Steps to reproduce:

Load 2 security devices (PKCS#11) on Windows x64 - in my case the first is Module name "B-Trust CryptoVision" (Path: "cvP11.dl"l) and "B-Trust Gemalto"(Path: "idprimepkcs11.dll"). PKCS#11 Libraries can be found in the attached file.


Actual results:

1. Load page that requires client authentication. In my case that is https://test.b-trust.org/.
2. The PIN window appears.
3. Enter correct PIN.
4. The windows to choose a certificate appears.
5. When click OK, Firefox shows connecting but notthing happens. 


Expected results:

This all works fine on Firefox version 49. The page with client authentication is successfully loaded.

Comment 1

[Loic]

Maybe duplicate of bug 1304407?

Tim, any thoughts?

Comment 2

[Tim Taubert [:ttaubert] (inactive)]

(In reply to Loic from comment #1)
> Maybe duplicate of bug 1304407?
> 
> Tim, any thoughts?

That seems quite likely. It started with 49, and cipherscan tells me that "DHE-RSA-AES256-SHA" is at the top, i.e. a cipher suite with SHA-384 as the PRF. If the issue is fixed with Firefox 51 it should definitely be a duplicate.

Comment 3

[dessy.vutova]

Hello, I have just tried with version with 51.0a2. The situation here is bit different from the version 49. Everything is OK if the 2 security devices are loaded but only one smart card token is inserted. If 2 tokens, not depending if the second token is from the same or different type, are inserted in the same type the PIN dialog for the first token is displayed, then the PIN dialog for the second is displayed, then the dialog to choose a certificate is display and when I click OK Firefox freezes. This behaviour does not depends on the certificate chosen ( I have tried to the first, the second and the result is the same).

Comment 4

[Tim Taubert [:ttaubert] (inactive)]

Kai, do you have any idea what might be happening here? Or any way to reproduce this? I possess no knowledge of our token/pin dialog code, or have any devices to test with.

Comment 5

[Kai Engert [:KaiE:]]

Adding Bob and Hubert to CC, in the hope they can contribute ideas towards an analysis.

Comment 6

[Kai Engert [:KaiE:]]

Could this be some kind of deadlock, when two devices require a pin entry, and the code that handles the password prompts isn't prepared for this kind of concurrency?

Comment 7

[c.haul]

I believe I'm stuck with the same problem. I'm running FF beta (ATM 61.0b5) but the issue is existing for some time.

When I connect to a SAML 2.0 site, all goes well including smartcard unlock and certificate selection but then the complete FF process hangs.

I have two security devices active: MS virtual smartcard and Broadcom Contacted Smartcard.

When I dump the process from process explorer and run analysis, it shows

-
  Detected a serious critical section related problem in firefox.dmp
  Lock at 0x000000d3`f64b1730 is Uninitialized

  Impact analysis
  3,03% of threads blocked
  (Threads 7 23)
-

-
  Locked critical section report

  Critical Section    0x000000d3`f64b1730  
  Lock State   Uninitialized 
  Lock Count   2 
  Recursion Count   1 
  Entry Count   0 
  Contention Count   0 
  Spin Count   16778716 
  Owner Thread System ID   12852 (not present in dump) 
-

And for the threads:

-
Thread 7 - System ID 7800
Entry point   ntdll!RtlUserThreadStart+34 
Create time   17.05.2018 15:05:18 
Time spent in user mode   0 Days 00:00:02.859 
Time spent in kernel mode   0 Days 00:00:03.281 

This thread is not fully resolved and may or may not be a problem. Further analysis of these threads may be required.

Function 
ntdll!NtWaitForSingleObject+a 
ntdll!RtlpWaitOnCriticalSection+e1 
ntdll!RtlpEnterCriticalSectionContended+a4 
nss3!PR_Lock+1f 
nss3!PK11_IsReadOnly+1e4c 
nss3!PK11_IsReadOnly+2cca 
nss3!PK11_IsHW+432f 
nss3!PK11_IsHW+469f 
nss3!PK11_IsHW+4117 
nss3!CERT_CertChainFromCert+96 
nss3!SSL_SignatureSchemePrefSet+1287 
nss3!SSL_SignatureSchemePrefSet+3436 
nss3!SSL_SignatureSchemePrefSet+540a 
nss3!SSL_SignatureSchemePrefSet+4de5 
nss3!SSL_SignatureSchemePrefSet+4bd5 
nss3!SSL_SignatureSchemePrefSet+51c5 
nss3!SSL_SignatureSchemePrefSet+5abd 
nss3!SSL_SignatureSchemePrefSet+10c0c 
nss3!SSL_ForceHandshake+d9 
xul!mozilla_dump_image+1422451 
xul+9498d2 
xul+948e42 
xul+a8eb27 
xul+a82cf6 
xul+a81275 
xul+683764 
xul+6825e6 
xul+4bee6f 
xul+911222 
xul+911150 
xul+8f4a21 
xul+8f49c6 
xul+8f5dee 
nss3!PRP_TryLock+62a 
nss3!PR_MD_UNLOCK+127e 
ucrtbase!thread_start<unsigned int (__cdecl*)(void * __ptr64)>+39 
kernel32!BaseThreadInitThunk+22 
ntdll!RtlUserThreadStart+34 
-

and

-
Thread 23 - System ID 10484
Entry point   ntdll!RtlUserThreadStart+34 
Create time   17.05.2018 15:05:18 
Time spent in user mode   0 Days 00:00:01.875 
Time spent in kernel mode   0 Days 00:00:03.078 

This thread is not fully resolved and may or may not be a problem. Further analysis of these threads may be required.

Function 
ntdll!NtWaitForSingleObject+a 
ntdll!RtlpWaitOnCriticalSection+e1 
ntdll!RtlpEnterCriticalSectionContended+a4 
nss3!PR_Lock+1f 
nss3!PK11_IsReadOnly+1bf2 
nss3!PK11_IsReadOnly+2b50 
nss3!PK11_IsReadOnly+2afa 
nss3!CERT_NewTempCertificate+78 
nss3!CERT_DecodeCertFromPackage+5f 
xul!mozilla_dump_image+14165c6 
xul!mozilla_dump_image+141bca1 
xul+946c60 
xul!mozilla_dump_image+141bb66 
xul+946c60 
xul+948c66 
xul!mozilla_dump_image+1428667 
xul+946c60 
xul+948c66 
xul!mozilla_dump_image+1407050 
xul+946c60 
xul+71cf4c 
xul!workerlz4_decompress+468e1b 
xul+9bf6c4 
xul+9bf51e 
xul+863e80 
xul+863bd8 
xul+863897 
xul+b752ca 
xul+b74faf 
xul!workerlz4_decompress+469ed9 
xul+c4e4d1 
xul+578054 
xul+5782ff 
xul!workerlz4_maxCompressedSize+55c7 
nss3!PRP_TryLock+62a 
nss3!PR_MD_UNLOCK+127e 
ucrtbase!thread_start<unsigned int (__cdecl*)(void * __ptr64)>+39 
kernel32!BaseThreadInitThunk+22 
ntdll!RtlUserThreadStart+34 
-

Comment 8

[c.haul]

Quick thumbs up: still persists with 64.0b4

Locked critical section report
Critical Section    0x00000092`e46dfd30  
Lock State   Uninitialized 
Lock Count   1 
Recursion Count   1 
Entry Count   0 
Contention Count   0 
Spin Count   16778716 
Owner Thread System ID   5480 (not present in dump) 

Thread 6 - System ID 11212
Entry point   ntdll!RtlUserThreadStart+34 
Create time   31.10.2018 11:24:24 
Time spent in user mode   0 Days 00:00:01.781 
Time spent in kernel mode   0 Days 00:00:02.609 

This thread is not fully resolved and may or may not be a problem. Further analysis of these threads may be required.

Function 
ntdll!NtWaitForSingleObject+a 
ntdll!RtlpWaitOnCriticalSection+e1 
ntdll!RtlpEnterCriticalSectionContended+a4 
nss3!PL_CompareValues+f8dc 
nss3!PL_CompareValues+109da 
nss3!PL_CompareValues+7860 
nss3!CERT_CertChainFromCert+91 
nss3!SSL_GetStatistics+7e1f 
nss3!SSL_GetStatistics+eeea 
nss3!SSL_GetStatistics+1356f 
nss3!SSL_GetStatistics+1460e 
nss3!SSL_SignatureSchemePrefSet+9c9a 
nss3!SSL_ForceHandshake+147 
xul!mozilla_dump_image+20a3544 
xul!XRE_GetBootstrap+6b8a32 
xul!XRE_GetBootstrap+6b7f21 
xul!XRE_GetBootstrap+6b7dcc 
xul!XRE_GetBootstrap+6b1f7c 
xul!XRE_GetBootstrap+6b15b7 
xul!XRE_GetBootstrap+452c1 
xul!XRE_GetBootstrap+40ed4 
xul!XRE_GetBootstrap+40829 
xul!XRE_GetBootstrap+4056e 
xul!XRE_GetBootstrap+1ee38 
xul!XRE_GetBootstrap+3f9b8 
nss3!PRP_TryLock+8aa 
nss3!PR_MD_UNLOCK+213a 
ucrtbase!thread_start<unsigned int (__cdecl*)(void * __ptr64)>+3e 
kernel32!BaseThreadInitThunk+22 
mozglue!DllBlocklist_Initialize+db5 
ntdll!RtlUserThreadStart+34

Comment 9

[Dana Keeler (she/her) [:keeler]]

Is this still happening?

Comment 10

[BugBot [:suhaib / :marco]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:beurdouche, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 11

[BugBot [:suhaib / :marco]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:beurdouche, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.