-
Notifications
You must be signed in to change notification settings - Fork 20
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
Potential unsoundnesses (not yet determined) with use of unsafe #37
Comments
This was referenced Oct 30, 2024
Closed
Alexhuszagh
added a commit
to Alexhuszagh/fast-float-rust
that referenced
this issue
Oct 31, 2024
This patches a lot of the wrappers in `AsciiStr` being marked as safe but not being safe except within the context, using raw pointer dereferences without local bounds checks. This is extensively documented in aldanor#37: aldanor#37 `AsciiStr` has been re-written as a result, and unsafe functions marked as safe have been either converted to safe variants where the compiled checks can be ellided or marked as unsafe so the caller knows to upholds the safety invariants.
This was referenced Oct 31, 2024
This was referenced Nov 9, 2024
This was referenced Nov 26, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi!
In the process of unsafe-reviewing this crate, we discovered some issues. It's as of yet unclear if there is any unsoundness here, however the invariants are sufficiently nonlocal that it warrants further review (which I may not have time for at the moment)
Most of these are of the form "unsafe precondition checked by debug assertion; and may be exposed to the user through many layers of API"
The first one is this code:
fast-float-rust/src/binary.rs
Lines 75 to 85 in 83a49b8
The safety invariants are upheld by a debug assertion, but it's not guarded in release mode. Ultimately, the
q
value comes from a parsed exponent, which seems quite sketchy: you really do not want safety invariants relying on outputs of your parsers: indeed: this is one of the most common ways for there to be exploitable undefined behavior in C code.fast-float-rust/src/common.rs
Lines 22 to 23 in 83a49b8
This doesn't do any bounds checking. It's possible the many uses of
step_by()
andstep()
in this codebase are correct, but it will take time to verify.There are a couple ways to use typestate to write munchers that can avoid duplicating bounds checks here so that the code can be written with the same performance. Happy to talk about that in more depth.
fast-float-rust/src/common.rs
Line 39 in 83a49b8
This also doesn't check invariants. Unclear if upheld at the call site.
fast-float-rust/src/common.rs
Lines 158 to 169 in 83a49b8
Only checks invariants in debug mode. Unclear if upheld at the call sites.
The text was updated successfully, but these errors were encountered: