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

Dependencies

(9 total, 7 outdated, 2 possibly insecure)

CrateRequiredLatestStatus
 bytes^0.41.6.0out of date
 flatbuffers ⚠️^0.5.023.5.26out of date
 futures^0.10.3.30out of date
 log^0.40.4.21up to date
 parity-multiaddr^0.2.00.11.2out of date
 tentacle-secio^0.10.6.1out of date
 tokio ⚠️^0.11.36.0out of date
 tokio-threadpool^0.10.1.18up to date
 tokio-yamux^0.10.3.8out of date

Dev dependencies

(6 total, 4 outdated)

CrateRequiredLatestStatus
 crossbeam-channel^0.3.60.5.12out of date
 env_logger^0.6.00.11.3out of date
 fnv^1.01.0.7up to date
 generic-channel^0.2.00.2.0up to date
 nix^0.13.00.28.0out of date
 systemstat^0.1.30.2.3out of date

Security Vulnerabilities

flatbuffers: Unsound `impl Follow for bool`

RUSTSEC-2019-0028

The implementation of impl Follow for bool allows to reinterpret arbitrary bytes as a bool.

In Rust bool has stringent requirements for its in-memory representation. Use of this function allows to violate these requirements and invoke undefined behaviour in safe code.

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.

tokio: Data race when sending and receiving after closing a `oneshot` channel

RUSTSEC-2021-0124

If a tokio::sync::oneshot channel is closed (via the oneshot::Receiver::close method), a data race may occur if the oneshot::Sender::send method is called while the corresponding oneshot::Receiver is awaited or calling try_recv.

When these methods are called concurrently on a closed channel, the two halves of the channel can concurrently access a shared memory location, resulting in a data race. This has been observed to cause memory corruption.

Note that the race only occurs when both halves of the channel are used after the Receiver half has called close. Code where close is not used, or where the Receiver is not awaited and try_recv is not called after calling close, is not affected.

See tokio#4225 for more details.