Sounds to me like the unsafe block had the wrong scope. If safe Rust called a function with a buffer, and that buffer was too small, and that function internally used unsafe code to write to the buffer, then that function is leaking the unsafety past the `unsafe {}` scope, which is incorrect. So that function should be marked as `unsafe`, and the calling code (which calculates the buffer) is then responsible for ensuring that it's invoking the unsafe function with an appropriately-sized buffer.
Re:The Rust Libs Blitz
by Manishearth on Friday May 05, 2017 @05:24PM
(#14276945)
Not necessarily. This isn't a question with a single answer within the community; there are reasons to tightly scope unsafe, and there are reasons to scope it to the full extent of unsafe-affecting invariants.
Scope your unsafe however you want, but check the invariants when auditing, and make sure they don't escape the module.
Re:The Rust Libs Blitz
by Manishearth on Friday May 05, 2017 @05:23PM
(#14276940)
I'm aware. When I say "audit a line of unsafe" that includes all the invariants that it relies on, which could be outside the block.
This is still not that hard.
You have to audit more than just the lines within the unsafe block. For example, I discovered a buffer overflow in a Rust library this week that was caused by an integer overflow outside the unsafe block[1]. The unsafe code itself was written correctly.
[1] https://github.com/RustSec/advisory-db/blob/master/crates/ba...