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>()]));
}

Anyone who uses total_size(..) function to partial read the length of any FixVec will get an incorrect result, due to an incorrect implementation. This has been resolved in the 0.7.2 release.

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.

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.