nanorand 0.5.0 - RNGs failed to generate properly for non-64-bit numbers

In versions of nanorand prior to 0.5.1, RandomGen implementations for standard unsigned integers could fail to properly generate numbers, due to using bit-shifting to truncate a 64-bit number, rather than just an as conversion. This often manifested as RNGs returning nothing but 0, including the...

dces' World type can cause data races

The World type in dces is marked as Send without bounds on its EntityStore and ComponentStore. This allows non-thread safe EntityStore and ComponentStores to be sent across threads and cause data races...

Thex<T> allows data races of non-Send types across threads

thex::Thex implements Sync for all types T. However, it is missing a bound for T: Send. This allows non-Send types such as Rc to be sent across thread boundaries which can trigger undefined behavior and memory corruption...

ArcGuard's Send and Sync should have bounds on RC

Affected versions of this crate implement Send/Sync for ArcGuard with no trait bounds on RC. This allows users to send RC: !Send to other threads and also allows users to concurrently access Rc: !Sync from multiple threads. This can result in memory corruption from data race or other undefined...

Future<T> lacks bounds on Send and Sync.

tinyfuture contains a light-weight implementation of Futures. The Future type it has lacked bound on its Send and Sync traits. This allows for a bug where non-thread safe types such as Cell can be used in Futures and cause data races in concurrent programs. The flaw was corrected in commit c79191...

ImageChunkMut needs bounds on its Send and Sync traits

In the affected versions of this crate, ImageChunkMut unconditionally implements Send and Sync, allowing to create data races. This can result in a memory corruption or undefined behavior when non thread-safe types are moved and referenced across thread boundaries. The flaw was corrected in commi...

crate has been superseded by `sn_client`

This crate has been superseded by snclient. The new repository location is:...

crate has been renamed to `sn_client`

This crate has been renamed from safecore to snclient. The new repository location is:...

crate has been renamed to `sn_node`

This crate has been renamed from safevault to snnode. The new repository location is:...

crate has been superseded by `sn_client`

This crate has been superseded by snclient. The new repository location is:...

ordered_float:NotNan may contain NaN after panic in assignment operators

After using an assignment operators such as NotNan::addassign, NotNan::mulassign, etc., it was possible for the resulting NotNan value to contain a NaN. This could cause undefined behavior in safe code, because the safe NotNan::cmp method contains internal unsafe code that assumes the value is...

memmap is unmaintained

The author of the memmap crate is unresponsive. Maintained alternatives: - memmap2...

Unsound: can make `ARefss` contain a !Send, !Sync object.

ARefss is a type that is assumed to contain objects that are Send + Sync. In the affected versions of this crate, Send/Sync traits are unconditionally implemented for ARefss. By using the ARefss::map API, we can insert a !Send or !Sync object into ARefss. After that, it is possible to create a da...

MPMCConsumer/Producer allows sending non-Send type across threads

Affected versions of this crate unconditionally implemented Sync and Send traits for MPMCConsumer and MPMCProducer types. This allows users to send types that do not implement Send trait across thread boundaries, which can cause a data race. The flaw was corrected in the 2.0.1 release by adding T...

Send bound needed on T (for Send impl of `Bucket2`)

Affected versions of this crate unconditionally implements Send for Bucket2. This allows sending non-Send types to other threads. This can lead to data races when non Send types like Cell or Rc are contained inside Bucket2 and sent across thread boundaries. The data races can potentially lead to...

Unexpected panic when decoding tokens

Prior to 0.10.0 it was possible to have both decoding functions panic unexpectedly, by supplying tokens with an incorrect base62 encoding. The documentation stated that an error should have been reported instead...

Reference counting error in `From<Py<T>>`

A bug in From would lead to an extra reference count decrement, often leading to use-after-free issues...

Cache<K>: Send/Sync impls needs trait bounds on `K`

Affected versions of this crate unconditionally implement Send/Sync for Cache. This allows users to insert K that is not Send or not Sync. This allows users to create data races by using non-Send types like Arc or Rc as K in Cache. It is also possible to create data races by using types like Cell...

QueueSender<T>/QueueReceiver<T>: Send/Sync impls need `T: Send`

Affected versions of this crate unconditionally implemented Send/Sync for QueueSender, allowing to send non-Send T to other threads by invoking &QueueSender.send. This fails to prevent users from creating data races by sending types like Rc or Arc to other threads, which can lead to memory...

convec::ConVec<T> unconditionally implements Send/Sync

Affected versions of this crate unconditionally implement Send/Sync for ConVec. This allows users to insert T that is not Send or not Sync. This allows users to create data races by using non-Send types like Arc or Rc as T in ConVec. It is also possible to create data races by using types like Ce...

Potential segfault in the time crate

Impact The affected functions set environment variables without synchronization. On Unix-like operating systems, this can crash in multithreaded programs. Programs may segfault due to dereferencing a dangling pointer if an environment variable is read in a different thread than the affected...

TryMutex<T> allows sending non-Send type across threads

Affected versions of this crate unconditionally implemented Sync trait for TryMutex type. This allows users to put non-Send T type in TryMutex and send it to another thread, which can cause a data race. The flaw was corrected in the 0.3.0 release by adding T: Send bound for the Sync trait...

Slock<T> allows sending non-Send types across thread boundaries

Slock unconditionally implements Send/Sync. Affected versions of this crate allows sending non-Send types to other threads, which can lead to data races and memory corruption due to the data race...

ReadTicket and WriteTicket should only be sendable when T is Send

Affected versions of this crate unconditionally implemented Send for ReadTicket & WriteTicket. This allows to send non-Send T to other threads. This can allows creating data races by cloning types with internal mutability and sending them to other threads as T of ReadTicket/WriteTicket. Such data...

Generators can cause data races if non-Send types are used in their generator functions

The Generator type is an iterable which uses a generator function that yields values. In affected versions of the crate, the provided function yielding values had no Send bounds despite the Generator itself implementing Send. The generator function lacking a Send bound means that types that are...

Singleton lacks bounds on Send and Sync.

Singleton is meant to be a static object that can be initialized lazily. In order to satisfy the requirement that static items must implement Sync, Singleton implemented both Sync and Send unconditionally. This allows for a bug where non-Sync types such as Cell can be used in singletons and cause...

Data race and memory safety issue in `Index`

The appendix crate implements a key-value mapping data structure called Index that is stored on disk. The crate allows for any type to inhabit the generic K and V type parameters and implements Send and Sync for them unconditionally. Using a type that is not marked as Send or Sync with Index can...

SyncChannel<T> can move 'T: !Send' to other threads

Affected versions of this crate unconditionally implement Send/Sync for SyncChannel. SyncChannel doesn't provide access to &T but merely serves as a channel that consumes and returns owned T. Users can create UB in safe Rust by sending T: !Send to other threads with SyncChannel::send/recv APIs...

PinSlab<T> and Unordered<T, S> need bounds on their Send/Sync traits

Affected versions of this crate unconditionally implemented Send & Sync for types PinSlab & Unordered. This allows sending non-Send types to other threads and concurrently accessing non-Sync types from multiple threads. This can result in a data race & memory corruption when types that provide...

Queue<T> should have a Send bound on its Send/Sync traits

Affected versions of this crate unconditionally implements Send/Sync for Queue. This allows 1 creating data races to a T: !Sync and 2 sending T: !Send to other threads, resulting in memory corruption or other undefined behavior...

CopyCell lacks bounds on its Send trait allowing for data races

CopyCell is a Cell-like type that is implemented for any type T that is Copyable. It's Send trait has no bounds on the contained type. As not all Copyable types are thread safe, for example non-mutable references implement the Copy trait, it is possible to send references to types with interior...

Send/Sync bound needed on T for Send/Sync impl of RcuCell<T>

Affected versions of this crate unconditionally implement Send/Sync for RcuCell. This allows users to send T: !Send to other threads while T enclosed within RcuCell, and allows users to concurrently access T: !Sync by using the APIs of RcuCell that provide access to &T. This can result in memory...

`LockWeak<T>` allows to create data race to `T`.

In the affected versions of this crate, LockWeak unconditionally implemented Send with no trait bounds on T. LockWeak doesn't own T and only provides &T. This allows concurrent access to a non-Sync T, which can cause undefined behavior like data races...

Send/Sync bound needed on V in `impl Send/Sync for ARCache<K, V>`

Affected versions of this crate unconditionally implemented Send/Sync traits for ARCache type. This allows users to send/access types that do not implement Send/Sync, which can cause a data race. The flaw was corrected in the 0.2.6 release by adding bounds K: Send + Sync & V: Send + Sync to...

`miow` invalidly assumes the memory layout of std::net::SocketAddr

The miow crate has assumed std::net::SocketAddrV4 and std::net::SocketAddrV6 have the same memory layout as the system C representation sockaddr. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the...

Mutable reference with immutable provenance

A mutable reference to a struct was constructed by dereferencing a pointer obtained from slice::asptr. Instead, slice::asmutptr should have been called on the mutable slice argument. The former performs an implicit reborrow as an immutable shared reference which does not allow writing through the...

Bunch<T> unconditionally implements Send/Sync

Affected versions of this crate unconditionally implements Send/Sync for Bunch. This allows users to insert T: !Sync to Bunch. It is possible to create a data race to a T: !Sync by invoking the Bunch::get API which returns &T from multiple threads. It is also possible to send T: !Send to other...

Argument injection in sendmail transport

Affected versions of lettre allowed argument injection to the sendmail command. It was possible, using forged to addresses, to pass arbitrary arguments to the sendmail executable. Depending on the implementation original sendmail, postfix, exim, etc. it could be possible in some cases to write...

hashconsing's HConsed lacks Send/Sync bound for its Send/Sync trait.

Affected versions of hashconsing implements Send/Sync for its HConsed type without restricting it to Sendable types and Syncable types. This allows non-Sync types such as Cell to be shared across threads leading to undefined behavior and memory corruption in concurrent programs...

`Decoder<R>` can carry `R: !Send` to other threads

Affected versions of this crate implements Send for Decoder for any R: Read. This allows Decoder to contain R: !Send and carry move it to another thread. This can result in undefined behavior such as memory corruption from data race on R, or dropping R = MutexGuard from a thread that didn't lock...

AtomicBox<T> implements Send/Sync for any `T: Sized`

Affected versions of this crate implements Send/Sync for AtomicBox without requiring T: Send/T: Sync. This allows to create data races to T: !Sync and send T: !Send to another thread. Such behavior breaks the compile-time thread safety guarantees of Rust, and allows users to incur undefined...

may_queue's Queue lacks Send/Sync bound for its Send/Sync trait.

Affected versions of mayqueue implements Send/Sync for its Queue type without restricting it to Sendable types and Syncable types. This allows non-Sync types such as Cell to be shared across threads leading to undefined behavior and memory corruption in concurrent programs...

LateStatic has incorrect Sync bound

Affected versions of this crate implemented Sync for LateStatic with T: Send, so that it is possible to create a data race to a type T: Send + !Sync e.g. Cell. This can result in a memory corruption or other kinds of undefined behavior. The flaw was corrected in commit 11f396c by replacing the T:...

`Shared` can cause a data race

Shared data structure in model crate implements Send and Sync traits regardless of the inner type. This allows safe Rust code to trigger a data race, which is undefined behavior in Rust. Users are advised to treat Shared as an unsafe type. It should not be used outside of the testing context, and...

Potential segfault in `localtime_r` invocations

Impact Unix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library...

AtomicBox<T> lacks bound on its Send and Sync traits allowing data races

AtomicBox is a Box type designed to be used across threads, however, it implements the Send and Sync traits for all types T. This allows non-Send types such as Rc and non-Sync types such as Cell to be used across thread boundaries which can trigger undefined behavior and memory corruption...

ReaderResult should be bounded by Sync

Affected versions of this crate implements Sync for ReaderResult with the trait bound T: Send, E: Send. Since matching on the public enum ReaderResult provides access to &T & &E, allowing data race to a non-Sync type T or E. This can result in a memory corruption when multiple threads concurrentl...

TreeFocus lacks bounds on its Send and Sync traits

Affected versions of im contains TreeFocus that unconditionally implements Send and Sync. This allows a data race in safe Rust code if TreeFocus is extracted from Focus type. Typical users that only use Focus type are not affected...

Unexpected panic in multihash `from_slice` parsing code

In versions prior 0.11.3 it's possible to make fromslice panic by feeding it certain malformed input. It's never documented that fromslice and frombytes which wraps it can panic, and its' return type Result suggests otherwise. In practice, fromslice/frombytes is frequently used in networking code...

Some lock_api lock guard objects can cause data races

Affected versions of lockapi had unsound implementations of the Send or Sync traits for some guard objects, namely: MappedMutexGuard MappedRwLockReadGuard MappedRwLockWriteGuard RwLockReadGuard RwLockWriteGuard These guards could allow data races through types that are not safe to Send across...