>And the error(s) in arithmetic occurred outside any unsafe block. This is completely misleading. The unsound check for integer overflow[0] was in 'safe' code

>And the error(s) in arithmetic occurred outside any unsafe block. This is completely misleading. The unsound check for integer overflow[0] was in 'safe' code but just because the code is not in an unsafe block does not absolve you of any potential bugs, and the subsequent writes to memory that were in an unsafe block clearly did not care about prior mistakes that were made. The PR that introduced the vulnerability[1] was due from switching a safe method to one that uses unsafe for performance reasons, I suggest checking out the commits for both the introduction of this bug as well as the commit that fixed it as they're both short and the actual bug only occurs on one short line. It's also worth noting that the vulnerability could have been found using a fuzzer[2] that did not exist (for Rust) at the time but that does now exist, and that integer overflows are checked for on debug builds (but not for release builds by default, again due to performance reasons) but that in this particular vulnerability it would have been extremely unlikely that any legitimate code would have triggered this integer overflow. The take away here isn't that 'even 'safe' languages get it wrong', but that unsafe operations are difficult to do correctly, and that's true in either C or Rust. There's further discussion[3] on this bug if anybody is interested. [0] https://github.com/rust-lang/rust/pull/54397 https://github.com/rust-lang/rust/pull/54397 [1] https://github.com/rust-lang/rust/pull/48657 https://github.com/rust-lang/rust/pull/48657 [2] https://medium.com/@shnatsel/how-ive-found-vulnerability-in-a-popular-rust-crate-and-you-can-too-3db081a67fb https://medium.com/@shnatsel/how-ive-found-vulnerability-in-... [3] https://internals.rust-lang.org/t/pre-rfc-fixed-capacity-view-of-vec/8413/35 https://internals.rust-lang.org/t/pre-rfc-fixed-capacity-vie...