-
Notifications
You must be signed in to change notification settings - Fork 833
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: wolfSSL reads/writes to global variables on first #7863
Comments
Hi @alexsn , Thanks for this bug report. I'll be looking into this for you. |
@anhu: possible fix for the above issue, feel free to use it as you see fit
|
@alexsn , Its great that you submitted a patch!! I will have a close look at it and review with my engineering team regarding next steps. |
Hi @alexsn . The setup code you're talking about here is idempotent, making it intrinsically safe (race-free). So there's no need to add any additional overhead. In particular, it's better to avoid reevaluating That said, I'll go ahead and add comments around these setup calls to highlight the dependence on idempotency. In any case, if you find any non-idempotent code with Thanks for the report. |
…ics re checkedAESNI, haveAESNI, intel_flags, and sha_method. see wolfSSL#7863.
Contact Details
[email protected]
Version
5.7.0
Description
We found multiple locations where wolfSSL reads/writes to global variables without locks cause which is not thread safe.
The following locations were detected by tsan:
static int transform_check
which is read from and written to by Sha512_SetTransform which can be called from multiple threads.wolfSSL_Init
so it doesn't suffer from this issue.static int checkedAESNI = 0; static int haveAESNI = 0;
both of which are read from and written to by wc_AesSetKeyLocalReproduction steps
Those issues are obvious by looking at the code links above, I expect all global inits to occur on
wolfSSL_Init
and not on first use.Relevant log output
The text was updated successfully, but these errors were encountered: