cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: problem with NSS backend and threads

From: Kamil Dudka <kdudka_at_redhat.com>
Date: Tue, 23 Aug 2016 16:49:06 +0200

On Tuesday, August 23, 2016 10:49:23 Peter Wang wrote:
> On Mon, 22 Aug 2016 15:27:23 +0200, Kamil Dudka <kdudka_at_redhat.com> wrote:
> > Thank you for analyzing the cause of it! After having a brief look at the
> > code, I believe the race condition is obvious:
> >
> > PK11_FindSlotByName() acquires only a "read" lock, which does not ensure
> > mutual exclusion of readers. So multiple calls of PK11_FindSlotByName()
> > can be executed in parallel. As there is no additional lock on the way,
> > nssSlot_IsTokenPresent() can also be executed in parallel.
> >
> > If there is a schedule where one thread has assigned slot->lastTokenPing
> > but not yet set the CKF_TOKEN_PRESENT flag in slot->ckFlags, all other
> > threads will keep returning SEC_ERROR_NO_TOKEN (without actually checking
> > presence of the token) until the first thread continues (or the specified
> > timeout elapses).
> >
> > In order to fix it, we need to add a mutex to nssSlot_IsTokenPresent() or
> > at least reorder mutation of slot's state such that slot->lastTokenPing is
> > not updated before the CKF_TOKEN_PRESENT flag in slot->ckFlags is updated.
> >
> > Could you please file it as a bug against NSS?
> >
> > https://bugzilla.mozilla.org/enter_bug.cgi#h=bugForm|NSS
> >
> > ... or should I file the bug on your behalf?
>
> Yes, please file the bug on my behalf. Thanks.

Done: https://bugzilla.mozilla.org/1297397

> Do you think it is practical to work around the problem in libcurl?

Sounds reasonable. I guess adding a mutex like the one you had in your
original post (but independent of crl) would do the job.

Any better idea?

Kamil

> Peter
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2016-08-23