Skip to content

Mild race condition in secp256k1_context_preallocated_create #351

Open
@Kixunil

Description

@Kixunil

Possible scenario:

  1. Assuming the context wasn't initialized yet
  2. Threads A and B loaded HAVE_PREALLOCATED_CONTEXT
  3. Thread A is suspended by the OS
  4. Thread B initializes the context and stores DONE
  5. Thread A is scheduled and swaps DONE for WORKING
  6. Thread C loads WORKING
  7. Thread A sees the mistake and stores DONE again
  8. Thread C can now continue

In this scenario C needlessly waited for A even though the context was initialized. I suggest to use compare exchange to avoid erroneous swapping in the first place.

There's also break missing so B always makes one more iteration of the loop and may even ironically become thread C.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions