Closed Bug 1679290 Opened 10 months ago Closed 10 months ago

regression: Bug 1663661 breaks cURL

Categories

(NSS :: Libraries, defect)

3.59
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: whissi, Assigned: kjacobs)

References

Details

Attachments

(4 files)

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 https://github.com/

Actual results:

cURL will hang forever:

$ curl -vv https://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 https://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?
Attached file Ubuntu log (no hang)

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?

Assignee: nobody → kjacobs.bugzilla
Flags: needinfo?(whissi)
Attached file how-to-reproduce.txt

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.

Flags: needinfo?(whissi)

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.

[[ https://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.

Status: UNCONFIRMED → RESOLVED
Closed: 10 months ago
Resolution: --- → FIXED
Target Milestone: --- → 3.60
Blocks: 1683004
You need to log in before you can comment on or make changes to this bug.