You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 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.
This doesn't do any bounds checking. It's possible the many uses of step_by() and step() 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.
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.
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: