InputStream::read_exact : `Read` on uninitialized buffer causes UB

Affected versions of this crate passes an uninitialized buffer to a user-provided Read implementation. Arbitrary Read implementations can read from the uninitialized buffer memory exposure and also can return incorrect number of bytes written to the buffer. Reading from uninitialized memory...

`Read` on uninitialized buffer in `fill_buf()` and `read_up_to()`

Affected versions of this crate passes an uninitialized buffer to a user-provided Read implementation. Arbitrary Read implementations can read from the uninitialized buffer memory exposure and also can return incorrect number of bytes written to the buffer. Reading from uninitialized memory...

Queues allow non-Send types to be sent to other threads, allowing data races

Affected versions of this crate unconditionally implemented Send for types used in queue implementations InnerSend, InnerRecv, FutInnerSend, FutInnerRecv. This allows users to send non-Send types to other threads, which can lead to data race bugs or other undefined behavior...

`Demuxer` can carry non-Send types across thread boundaries

In the affected versions of this crate, Demuxer unconditionally implemented Send with no trait bounds on T. This allows sending a non-Send type T across thread boundaries, which can cause undefined behavior like unlocking a mutex from a thread that didn't lock the mutex, or memory corruption from...

stderr is unmaintained; use eprintln instead

The stderr crate is no longer maintained by its current owner. The author recommends using the eprintln macro from the standard library as a replacement...

conquer-once's OnceCell lacks Send bound for its Sync trait.

Affected versions of conquer-once implements Sync for its OnceCell type without restricting it to Sendable types. This allows non-Send but Sync types such as MutexGuard to be sent across threads leading to undefined behavior and memory corruption in concurrent programs. The issue was fixed by...

Update unsound DrainFilter and RString::retain

Affected versions of this crate contained code from the Rust standard library that contained soundness bugs rust-lang/rust60977 double drop & rust-lang/rust78498 create invalid utf-8 string. The flaw was corrected in v0.9.1 by making a similar fix to the one made in the Rust standard library...

Soundness issue: Input<R> can be misused to create data race to an object

Input implements Send without requiring R: Send. Affected versions of this crate allows users to send non-Send types to other threads, which can lead to undefined behavior such as data race and memory corruption. The flaw was corrected in version 0.5.1 by adding R: Send bound to the Send impl of...

difference is unmaintained

The author of the difference crate is unresponsive. Maintained alternatives: - dissimilar - similar - treediff - diffus...

Queues allow non-Send types to be sent to other threads, allowing data races

Affected versions of this crate unconditionally implemented Send for types used in queue implementations InnerSend, InnerRecv, FutInnerSend, FutInnerRecv. This allows users to send non-Send types to other threads, which can lead to data race bugs or other undefined behavior. The flaw was correcte...

SyncRef's clone() and debug() allow data races

Affected versions of this crate unconditionally implement Sync for SyncRef. This definition allows data races if &T is accessible through &SyncRef. SyncRef derives Clone and Debug, and the default implementations of those traits access &T by invoking T::clone & T::fmt. It is possible to create da...

ShmWriter allows sending non-Send type across threads

Affected versions of this crate implement Send for ShmWriter without requiring H: Send. This allows users to send H: !Send to other threads, which can potentially lead to data races and undefined behavior...

ButtplugFutureStateShared allows data race to (!Send|!Sync) objects

ButtplugFutureStateShared implements Send & Sync regardless of T. If T: !Send for ButtplugFutureStateShared, it is possible to move non-Send types across thread boundaries e.g. T=Rc and lead to undefined behavior. If T: !Sync for ButtplugFutureStateShared, it is possible to cause data race to T...

UsbContext trait did not require implementers to be Send and Sync.

Affected versions of rusb did not require UsbContext to implement Send and Sync. However, through Device and DeviceHandle it is possible to use UsbContexts across threads. This issue allows non-thread safe UsbContext types to be used concurrently leading to data races and memory corruption. The...

ImmediateIO and TransactionalIO can cause data races

The ImmediateIO and TransactionalIO types implement Sync for all contained Expander types regardless of if the Expander itself is safe to use across threads. As the IO types allow retrieving the Expander, this can lead to non-thread safe types being sent across threads as part of the Expander...

RingBuffer can create multiple mutable references and cause data races

The RingBuffer type retrieves mutable references from the DataProvider in a non-atomic manner, potentially allowing the creation of multiple mutable references. RingBuffer also implements the Send and Sync traits for all types T. This allows undefined behavior from the aliased mutable references ...

Async-h1 request smuggling possible with long unread bodies

This vulnerability affects any webserver that uses async-h1 behind a reverse proxy, including all such Tide applications. If the server does not read the body of a request which is longer than some buffer length, async-h1 will attempt to read a subsequent request from the body content starting at...

Dangling reference in `access::Map` with Constant

Using the arcswap::access::Map with the Constant test helper or with user-provided implementation of the Access trait could sometimes lead to the map returning dangling references. Replaced by implementation without unsafe, at the cost of added Clone bound on the closure and small penalty on...

MvccRwLock allows data races & aliasing violations

Affected versions of this crate unconditionally implement Send/Sync for MvccRwLock. This can lead to data races when types that are either !Send or !Sync e.g. Rc, Arc are contained inside MvccRwLock and sent across thread boundaries. The data races can potentially lead to memory corruption as...

Soundness issue with base::Error

base::Error type contains public field named ptr. With this definition, it is possible to create a base::Error with an invalid pointer and trigger memory safety errors such as use-after-free or double-free with safe Rust. The users of xcb crate are advised not to manipulate the field...

Multiple soundness issues in `Ptr`

Affected versions of this crate have the following issues: 1. Ptr implements Send and Sync for all types, this can lead to data races by sending non-thread safe types across threads. 2. Ptr::get violates mutable alias rules by returning multiple mutable references to the same object. 3. Ptr::writ...

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

aovec::Aovec is a vector type that implements Send and Sync 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...

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...

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...

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...

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...

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...

crate has been renamed to `sn_client`

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

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_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...

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...

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...

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...

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...

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...

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...

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...

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...

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...

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...

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...

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...