Skip to content
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

fix: handle TLS deallocation #324

Merged
merged 1 commit into from
Feb 15, 2025
Merged

fix: handle TLS deallocation #324

merged 1 commit into from
Feb 15, 2025

Conversation

Stebalien
Copy link
Owner

Previously, creating a temporary file from a TLS destructor could panic in fastrand (because the thread-local RNG may have been deallocated).

Now, we fork the RNG before we create each file, falling back on an RNG with a static seed if the thread-local RNG has been deallocated.

Two downsides to this patch:

  1. Temporary files created during TLS deallocation will have extremely predictable names until the getrandom re-seed kicks in (assuming that feature is enabled). IMO, that's fine; this would panic previously.
  2. getrandom re-seeding used to re-randomize to the entire per-thread RNG, now it only applies to the per-filename RNG. However, the will still serve its purpose as a mitigation against potential DoS attacks.

I also considered managing the thread-local RNG myself instead of relying on fastrand, but that just isn't worth the added code, IMO.

Thanks to @stoeckmann for reporting this and explaining the issue to me. I went with this version instead of their version because I needed to keep tmpname as a separate function for some tempfile v4 changes.

fixes #281

NOTE: there are no tests because I can't actually trigger a crash no matter how I write the test. My test TLS slot is always deallocated first.

@Stebalien Stebalien force-pushed the steb/tls-deallocation branch from d096a0e to ddb6d3a Compare February 15, 2025 22:20
Previously, creating a temporary file from a TLS destructor could panic
in fastrand (because the thread-local RNG may have been deallocated).

Now, we fork the RNG before we create each file, falling back on an RNG
with a static seed if the thread-local RNG has been deallocated.

Two downsides to this patch:

1. Temporary files created during TLS deallocation will have extremely
predictable names until the `getrandom` re-seed kicks in (assuming that
feature is enabled). IMO, that's fine; this would panic previously.
2. `getrandom` re-seeding used to re-randomize to the entire per-thread
RNG, now it only applies to the per-filename RNG. However, the will
still serve its purpose as a mitigation against potential DoS attacks.

I also considered managing the thread-local RNG myself instead of
relying on fastrand, but that just isn't worth the added code, IMO.

Thanks to @stoeckmann for reporting this and explaining the issue to me.
I went with this version instead of their version because I needed to
keep `tmpname` as a separate function for some tempfile v4 changes.

fixes #281
@Stebalien Stebalien force-pushed the steb/tls-deallocation branch from ddb6d3a to fbfe87a Compare February 15, 2025 22:21
@Stebalien Stebalien merged commit 1e5059f into master Feb 15, 2025
14 checks passed
@Stebalien Stebalien deleted the steb/tls-deallocation branch February 15, 2025 22:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants