User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0

Steps to reproduce:

1. Compile cURL against nss-3.59
2. Try curl -vv http://github.com/

Actual results:

cURL will hang forever:

$ curl -vv http://github.com 1>/dev/null

• Trying 140.82.121.3:443...
  % Total % Received % Xferd Average Speed Time Time Time Current
  Dload Upload Total Spent Left Speed
  0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to github.com (140.82.121.3) port 443 (#0)
• Initializing NSS with certpath: none
• CAfile: none
  CApath: none
• loaded libnssckbi.so

Expected results:

cURL should be able to connect to github.com and fetch body.

This looks like similar problem as shown in bug 1672703. I bisect nss-3.59 and found that changes for bug 1663661 are causing the problem. When I revert http://hg.mozilla.org/projects/nss/rev/0ed11a5835ac1556ff978362cd61069d48f4c5db cURL will work again.

Thanks for the report. I haven't been able to reproduce this on Ubuntu, but I get a warning about libnsspem that's not in your snapshot.

• Are you using libnsspem, or do you get the same warning? If using libnsspem, does the hang reproduce without it?
• Are you using any other PKCS11 device or library with NSS?

Yes, nss-pem-1.0.6 is installed. Without nss-pem installed it's working (with same warning) like shown by you.

No PKCS11 device installed/attached. Just the library is installed.

I still haven't been able to reproduce this on Gentoo or Fedora, even with libnsspem configured.

Would you be able to apply the attached patch (to anything 3.59+) and give it a try?

Patch fixes the problem, thank you.

I attached a text file explaining how to set up a Gentoo chroot to reproduce the problem. I am able to reproduce on Debian and Fedora.

Kevin, why did you remove the comment in the header? It seems like following that rule is what fixed the problem. Would it be possible to assert that you don't hold the inner lock when entering the outer monitor?

(In reply to Martin Thomson [:mt:] from comment #6)

Kevin, why did you remove the comment in the header? It seems like following that rule is what fixed the problem. Would it be possible to assert that you don't hold the inner lock when entering the outer monitor?

My mistake. I already reverted the comment locally and will look into the assertion, then push to phabricator. The comment (though inaccurate at the time) was actually correct.

[[ http://hg.mozilla.org/projects/nss/rev/0ed11a5835ac1556ff978362cd61069d48f4c5db | 0ed11a5835ac1556ff978362cd61069d48f4c5db ]] fixed a number of race conditions related to NSSSlot member accesses. Unfortunately the locking order that was imposed by that patch has been found to cause problems for at least one PKCS11 module, libnsspem.

This patch drops nested locking in favor of unlocking/re-locking. While this isn't perfect, the original problem in bug 1663661 was that slot->token could become NULL, which we can easily check after reacquiring.

http://hg.mozilla.org/projects/nss/rev/19585ccc7a1f0f4e9a8d2b9c5ceeb408ea90acb9

Thank you for the report!

NSS_3_59_BRANCH: http://hg.mozilla.org/projects/nss/rev/e8f82b2381bc1109027533ffdc14bfc358f6f549