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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

`term_size` is unmaintained; use `terminal_size` instead

The termsize crate is no longer maintained. Consider using terminalsize instead...

Use-after-free when cloning a partially consumed `Vec` iterator

The IntoIter Clone implementation clones the whole underlying Vec. If the iterator is partially consumed the consumed items will be copied, thus creating a use-after-free access. A proof of concept is available in the original bug report...

crate has been renamed to `sn_fake_clock`

This crate has been renamed from fakeclock to snfakeclock. The new repository location is:...

crate has been renamed to `safe-nd`

This crate has been renamed from safe-nd to sndatatypes. The new repository location is:...

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

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

crate has been renamed to `sn_routing`

This crate has been renamed from routing to snrouting. The new repository location is:...

crate has been renamed to `sn_ffi_utils`

This crate has been renamed from ffiutils to snffiutils. The new repository location is:...

crate has been renamed to `sn_bindgen`

This crate has been renamed from safebindgen to snbindgen. The new repository location is:...

crate has been renamed to `qp2p`

This crate has been renamed from quic-p2p to qp2p. The new repository location is:...

GenericMutexGuard allows data races of non-Sync types across threads

GenericMutexGuard was given the Sync auto trait as long as T is Send due to its contained members. However, since the guard is supposed to represent an acquired lock and allows concurrent access to the underlying data from different threads, it should only be Sync when the underlying data is. Thi...

AtomicOption should have Send + Sync bound on its type argument.

In the affected versions of this crate, AtomicOption unconditionally implements Sync. This allows programmers to move non-Sync types across thread boundaries e.g. Rc, Arc, which can lead to data races and undefined behavior. It is also possible to send non-Send types like std::sync::MutexGuard to...

beef::Cow lacks a Sync bound on its Send trait allowing for data races

Affected versions of this crate did not have a T: Sync bound in the Send impl for Cow. This allows users to create data races by making Cow contain types that are Send && !Sync like Cell or RefCell. Such data races can lead to memory corruption. The flaw was corrected in commit d1c7658 by adding...

MutexGuard::map can cause a data race in safe code

Affected versions of the crate had a Send/Sync implementation for MappedMutexGuard that only considered variance on T, while MappedMutexGuard dereferenced to U. This could of led to data races in safe Rust code when a closure used in MutexGuard::map returns U that is unrelated to T. The issue was...

Please see RUSTSEC-2018-0020

This vulnerability was misfiled under the wrong year and has been withdrawn...

directories is unmaintained, use directories-next instead

The directories crate is not maintained any more; use directories-next instead...

dirs is unmaintained, use dirs-next instead

The dirs crate is not maintained any more; use dirs-next instead...

crate has been renamed to `cipher`

This crate has been renamed from stream-cipher to cipher. The new repository location is at:...

crate has been renamed to `cipher`

This crate has been renamed from block-cipher to cipher. The new repository location is at:...

Obsolete versions of the `rustsec` crate do not support the new V3 advisory format

If you are seeing this message, you are running an obsolete version of cargo-audit which does not support the new V3 advisory format. These versions are end-of-life. This advisory is a notice that that it will soon be unable to parse the advisory database. Please upgrade cargo-audit to a newer...

VecCopy allows misaligned access to elements

VecCopy::data is created as a Vec of u8 but can be used to store and retrieve elements of different types leading to misaligned access. The issue was resolved in v0.5.0 by replacing data being stored by Vec with a custom managed pointer. Elements are now stored and retrieved using types with prop...

array_queue pop_back() may cause a use-after-free

arrayqueue implements a circular queue that wraps around an array. However, it fails to properly index into the array in the popback function allowing the reading of previously dropped or uninitialized memory...

Insufficient size checks in outgoing buffer in ws allows remote attacker to run the process out of memory

Affected versions of this crate did not properly check and cap the growth of the outgoing buffer. This allows a remote attacker to take down the process by growing the buffer of their single connection until the process runs out of memory it can allocate and is killed. The flaw was corrected in t...

Missing check in ArrayVec leads to out-of-bounds write.

ArrayVec::insert allows insertion of an element into the array object into the specified index. Due to a missing check on the upperbound of this index, it is possible to write out of bounds...

Unsafe Send implementation in Atom allows data races

The atom crate contains a security issue revolving around its implementation of the Send trait. It incorrectly allows any arbitrary type to be sent across threads potentially leading to use-after-free issues through memory races...

Multiple soundness issues in Chunk and InlineArray

Chunk: Array size is not checked when constructed with unit and pair. Array size is not checked when constructed with From. Clone and insertfrom are not panic-safe; A panicking iterator causes memory safety issues with them. InlineArray: Generates unaligned references for types with a large...

personnummer Input validation error

Swedish personal identity is in the form of YYMMDD-XXXX An issue arises from the regular expression allowing the first three digits in the last four digits of the personnummer to be 000, which is invalid. To mitigate this without upgrading, a check on the last four digits can be made to make sure...