This project might be open to known security vulnerabilities, which can be prevented by tightening the version range of affected dependencies. Find detailed information at the bottom.

Crate tentacle-ping

Dependencies

(7 total, 3 outdated, 1 possibly insecure)

CrateRequiredLatestStatus
 bytes^0.41.6.0out of date
 flatbuffers ⚠️^0.6.023.5.26out of date
 flatbuffers-verifier^0.2.00.2.1up to date
 fnv^1.0.61.0.7up to date
 generic-channel^0.2.00.2.0up to date
 log^0.40.4.21up to date
 tentacle^0.2.00.4.2out of date

Security Vulnerabilities

flatbuffers: `read_scalar` and `read_scalar_at` allow transmuting values without `unsafe` blocks

RUSTSEC-2020-0009

The read_scalar and read_scalar_at functions are unsound because they allow transmuting values without unsafe blocks.

The following example shows how to create a dangling reference:

fn main() {
    #[derive(Copy, Clone, PartialEq, Debug)]
    struct S(&'static str);
    impl flatbuffers::EndianScalar for S {
        fn to_little_endian(self) -> Self { self }
        fn from_little_endian(self) -> Self { self }
    }
    println!("{:?}", flatbuffers::read_scalar::<S>(&[1; std::mem::size_of::<S>()]));
}

flatbuffers: Generated code can read and write out of bounds in safe code

RUSTSEC-2021-0122

Code generated by flatbuffers' compiler is unsafe but not marked as such. See https://github.com/google/flatbuffers/issues/6627 for details.

For example, if generated code is used to decode malformed or untrusted input, undefined behavior (and thus security vulnerabilities) is possible even without the use of the unsafe keyword, violating the the meaning of "safe" code;

All users that use generated code by flatbuffers compiler are recommended to:

  1. not expose flatbuffer generated code as part of their public APIs
  2. audit their code and look for any usage of follow, push, or any method that uses them (e.g. self_follow).
  3. Carefully go through the crates' documentation to understand which "safe" APIs are not intended to be used.