Missing Send bound for Lazy

All current versions of this crate allow causing data races in safe code. The flaw will be fixed in the next release...

panic safety: double drop may happen within `util::{mutate, mutate2}`

Upon panic in a user-provided function f, fn mutate & fn mutate2 drops twice a same object. Affected versions of this crate did not guard against double drop while temporarily duplicating an object's ownership with ptr::read. Dropping a same object can result in memory corruption. The flaw was...

panic safety: double drop or uninitialized drop of T upon panic

Affected versions of this crate did not guard against potential panics that may happen from user-provided functions T::default and T::drop. Panic within T::default leads to dropping uninitialized T, when it is invoked from common::Slice::::new. Panic within T::drop leads to double drop of T, when...

FromIterator implementation for Vector/Matrix can drop uninitialized memory

The FromIterator methods for Vector and Matrix rely on the type parameter N to allocate space in the iterable. If the passed in N type parameter is larger than the number of items returned by the iterator, it can lead to uninitialized memory being left in the Vector or Matrix type which gets...

Double drop upon panic in 'fn map_array()'

Affected versions of this crate did not guard against panic within the user-provided function f 2nd parameter of fn maparray, and thus panic within f causes double drop of a single object. The flaw was corrected in the 0.4.0 release by wrapping the object vulnerable to a double drop within...

panic safety issue in `impl TransformContent<S, D> for [S; (2|3|4)]`

Affected versions of this crate did not guard against double drop while temporarily duplicating objects' ownership using ptr::read. Upon panic in a user-provided function conversion, objects that are copied by ptr::read are dropped twice, leading to memory corruption. The flaw was corrected in...

Buffer overflow in SmallVec::insert_many

A bug in the SmallVec::insertmany method caused it to allocate a buffer that was smaller than needed. It then wrote past the end of the buffer, causing a buffer overflow and memory corruption on the heap. This bug was only triggered if the iterator passed to insertmany yielded more items than the...

Reading on uninitialized buffer may cause UB ( `gfx_auxil::read_spirv()` )

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

Loading a bgzip block can write out of bounds if size overflows.

Affected versions of bam set the length of an internal buffer using self.compressed.setlenblocksize - HEADERSIZE - MINEXTRASIZE and then wrote into it. While blocksize was constrained to a proper maximum, when it was too small the subtraction could overflow negatively to a large number past the...

columnar: `Read` on uninitialized buffer may cause UB (ColumnarReadExt::read_typed_vec())

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

Reading on uninitialized memory may cause UB ( `util::read_spv()` )

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 may cause UB ( `read_entry()` )

Affected versions of this crate passes an uninitialized buffer to a user-provided Read implementation. There are two of such cases gooffsetlog::readentry & offsetlog::readentry. Arbitrary Read implementations can read from the uninitialized buffer memory exposure and also can return incorrect...

`Frame::copy_from_raw_parts` can lead to segfault without `unsafe`

fn Frame::copyfromrawparts is a safe API that can take a raw pointer and dereference it. It is possible to read arbitrary memory address with an arbitrarily fed pointer. This allows the safe API to access & read arbitrary address in memory. Feeding an invalid memory address pointer to the API may...

`Sectors::get` accesses unclaimed/uninitialized memory

Affected versions of this crate arbitrarily calls Vec::setlen to increase length of a vector without claiming more memory for the vector. Affected versions of this crate also calls user-provided Read on the uninitialized memory of the vector that was extended with Vec::setlen. This can overwrite...

`Read` on uninitialized memory may cause UB (fn preamble_skipcount())

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

XSS in mdBook's search page

This is a cross-post of the official security advisoryml. The official post contains a signed version with our PGP key, as well. ml: https://groups.google.com/g/rustlang-security-announcements/c/3-sO6of29O0 The Rust Security Response Working Group was recently notified of a security issue affecti...

interfaces2 is unmaintained, use interfaces instead

The interfaces2 crate is not maintained any more; use interfaces instead...

kamadak-exif DoS with untrusted PNG data

Attacker crafted data can cause a infinite loop leading to DoS if used with untrusted data...

EventList's From<EventList> conversions can double drop on panic.

Affected versions of this crate read from a container using ptr::read in From, and then call a user specified Into function. This issue can result in a double-free if the user provided function panics...

panic in user-provided `Endian` impl triggers double drop of T

Affected versions of the crate does not guard against panic from user-provided impl of Endian trait, which is a safe trait that users can implement. If a user-provided implementation of the Endian trait panics, double-drop is triggered due to the duplicated ownership of T created by ptr::read...

`Read` on uninitialized buffer can cause UB (impl of `ReadKVExt`)

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 memory may cause UB

Affected versions of this crate passes an uninitialized buffer to a user-provided Read implementation. The crate currently contains 4 occurrences of such cases. Arbitrary Read implementations can read from the uninitialized buffer memory exposure and also can return incorrect number of bytes...

reading on uninitialized buffer can cause UB (`impl<R> BufRead for GreedyAccessReader<R>`)

Affected versions of this crate creates an uninitialized buffer and passes it to user-provided Read implementation. This is unsound, because it allows safe Rust code to exhibit an undefined behavior read from uninitialized memory. The flaw was corrected in version 0.1.1 by zero-initializing a new...

Reading uninitialized memory can cause UB (`Deserializer::read_vec`)

Deserializer::readvec created an uninitialized buffer and passes it to a user-provided Read implementation Deserializer.reader.readexact. Passing an uninitialized buffer to an arbitrary Read implementation is currently defined as undefined behavior in Rust. Official documentation for the Read tra...

Exposes internally used raw pointer

Affected versions of this crate dereference a raw pointer that can be modified without using unsafe code...

`read` on uninitialized buffer may cause UB (bite::read::BiteReadExpandedExt::read_framed_max)

Affected versions of this crate calls a user provided Read implementation on an uninitialized buffer. Read on uninitialized buffer is defined as undefined behavior in Rust...

`FixedCapacityDequeLike::clone()` can cause dropping uninitialized memory

Affected versions of this crate don't guard against panics, so that partially uninitialized buffer is dropped when user-provided T::clone panics in FixedCapacityDequeLike::clone. This causes memory corruption...

`impl Random` on arrays can lead to dropping uninitialized memory

Affected versions of this crate had a panic safety issue to drop partially uninitialized array of T upon panic in a user provided function T::random. Dropping uninitialized T can potentially cause memory corruption or undefined behavior. The flaw was corrected in commit 565d508 by using MaybeUnin...

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

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

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

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

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

difference is unmaintained

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

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

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

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

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

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

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

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

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

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

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

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

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