Summary: SSL/TLS MitM vulnerability due to insecure defaults

All versions of rust-openssl prior to 0.9.0 contained numerous insecure defaults
including off-by-default certificate verification and no API to perform hostname
verification.

Unless configured correctly by a developer, these defaults could allow an attacker
to perform man-in-the-middle attacks.

The problem was addressed in newer versions by enabling certificate verification
by default and exposing APIs to perform hostname verification. Use the
`SslConnector` and `SslAcceptor` types to take advantage of these new features
(as opposed to the lower-level `SslContext` type).


Summary: HTTPS MitM vulnerability due to lack of hostname verification

When used on Windows platforms, all versions of Hyper prior to 0.9.4 did not
perform hostname verification when making HTTPS requests.

This allows an attacker to perform MitM attacks by preventing any valid
CA-issued certificate, even if there's a hostname mismatch.

The problem was addressed by leveraging rust-openssl's built-in support for
hostname verification.


Summary: HTTP download and execution allows MitM RCE

The build script in the portaudio crate will attempt to download via HTTP
the portaudio source and build it.

A Mallory in the middle can intercept the download with their own archive
and get RCE.


Summary: libusb is unmaintained; use rusb instead

The `libusb` crate has not seen a release since September 2016, and its author
is unresponsive.

The `rusb` crate is a maintained fork:

https://github.com/a1ien/rusb


Summary: rust-crypto is unmaintained; switch to a modern alternative

The `rust-crypto` crate has not seen a release or GitHub commit since 2016,
and its author is unresponsive.

*NOTE: The (old) `rust-crypto` crate (with hyphen) should not be confused with
similarly named (new) [RustCrypto GitHub Org] (without hyphen). The GitHub Org
is actively maintained.*

We recommend you switch to one of the following crates instead, depending on
which algorithms you need:

- [dalek-cryptography GitHub Org]:
  - Key agreement: [`x25519-dalek`]
  - Signature algorithms: [`ed25519-dalek`]
- [`ring`]:
  - AEAD algorithms: AES-GCM, ChaCha20Poly1305
  - Digest algorithms: SHA-256, SHA-384, SHA-512, SHA-512/256 (legacy: SHA-1)
  - HMAC
  - Key agreement: ECDH (P-256, P-384), X25519
  - Key derivation: HKDF
  - Password hashing: PBKDF2
  - Signature algorithms: ECDSA (P-256, P-384), Ed25519, RSA (PKCS#1v1.5, PSS)
- [RustCrypto GitHub Org]:
  - AEAD algorithms: [`aes-gcm`], [`aes-gcm-siv`], [`aes-siv`], [`chacha20poly1305`], [`xsalsa20poly1305`]
  - Block ciphers: [`aes`], [`cast5`], [`des`]
  - Digest algorithms: [`sha2`], [`sha3`], [`blake2`], [`ripemd160`]
    (legacy: [`sha-1`], [`md-5`])
  - Key derivation: [`hkdf`]
  - MACs: [`cmac`], [`hmac`], [`pmac`], [`poly1305`]
  - Password hashing: [`pbkdf2`]
  - Stream ciphers: [`aes-ctr`], [`chacha20`], [`hc-256`], [`salsa20`]
- [`secp256k1`]:
  - Key agreement: ECDH (secp256k1 only)
  - Signature algorithms: ECDSA (secp256k1 only)
- [`orion`]:
  - AEAD algorithms: ChaCha20Poly1305 (IETF version), XChaCha20Poly1305
  - Digest algorithms: SHA-512, BLAKE2b
  - Key derivation: HKDF
  - MACs: HMAC, Poly1305
  - Password hashing: PBKDF2
  - Stream ciphers: ChaCha20 (IETF version), XChaCha20

[dalek-cryptography GitHub Org]: https://github.com/dalek-cryptography
[RustCrypto GitHub Org]: https://github.com/RustCrypto
[`aes`]: https://crates.io/crates/aes
[`aes-ctr`]: https://crates.io/crates/aes-ctr
[`aes-gcm`]: https://crates.io/crates/aes-gcm
[`aes-gcm-siv`]: https://crates.io/crates/aes-gcm-siv
[`aes-siv`]: https://crates.io/crates/aes-siv
[`blake2`]: https://crates.io/crates/blake2
[`cast5`]: https://crates.io/crates/cast5
[`chacha20`]: https://crates.io/crates/chacha20
[`chacha20poly1305`]: https://crates.io/crates/chacha20poly1305
[`cmac`]: https://crates.io/crates/cmac
[`des`]: https://crates.io/crates/des
[`ed25519-dalek`]: https://crates.io/crates/ed25519-dalek
[`hc-256`]: https://crates.io/crates/hc-256
[`hkdf`]: https://crates.io/crates/hkdf
[`hmac`]: https://crates.io/crates/hmac
[`pbkdf2`]: https://crates.io/crates/pbkdf2
[`pmac`]: https://crates.io/crates/pmac
[`poly1305`]: https://crates.io/crates/poly1305
[`ring`]: https://crates.io/crates/ring
[`ripemd160`]: https://crates.io/crates/ripemd160
[`salsa20`]: https://crates.io/crates/salsa20
[`secp256k1`]: https://crates.io/crates/secp256k1
[`sha-1`]: https://crates.io/crates/sha-1
[`sha2`]: https://crates.io/crates/sha2
[`sha3`]: https://crates.io/crates/sha3
[`x25519-dalek`]: https://crates.io/crates/x25519-dalek
[`xsalsa20poly1305`]: https://crates.io/crates/xsalsa20poly1305
[`orion`]: https://crates.io/crates/orion


Summary: `cassandra` crate is unmaintained; use `cassandra-cpp` instead

The `cassandra` crate has not seen a release since December 2016, and its author
is unresponsive.

The `cassandra-cpp` crate is a maintained fork:

https://github.com/Metaswitch/cassandra-rs


Summary: scalarmult() vulnerable to degenerate public keys

The `scalarmult()` function included in previous versions of this crate
accepted all-zero public keys, for which the resulting Diffie-Hellman shared
secret will always be zero regardless of the private key used.

This issue was fixed by checking for this class of keys and rejecting them
if they are used.


Summary: headers containing newline characters can split messages

Serializing of headers to the socket did not filter the values for newline bytes (`\r` or `\n`),
which allowed for header values to split a request or response. People would not likely include
newlines in the headers in their own applications, so the way for most people to exploit this
is if an application constructs headers based on unsanitized user input.

This issue was fixed by replacing all newline characters with a space during serialization of
a header value.


Summary: Hostname verification skipped when custom root certs used

If custom root certificates were registered with a `ClientBuilder`, the
hostname of the target server would not be validated against its presented leaf
certificate.

This issue was fixed by properly configuring the trust evaluation logic to
perform that check.


Summary: Integer overflow leads to heap-based buffer overflow in encode_config_buf

Affected versions of this crate suffered from an integer overflow bug when
calculating the size of a buffer to use when encoding base64 using the
`encode_config_buf` and `encode_config` functions.  If the input string
was large, this would cause a buffer to be allocated that was too small.
Since this function writes to the buffer using unsafe code, it would
allow an attacker to write beyond the buffer, causing memory corruption
and possibly the execution of arbitrary code.

This flaw was corrected by using checked arithmetic to calculate
the size of the buffer.


Summary: Large cookie Max-Age values can cause a denial of service

Affected versions of this crate use the `time` crate and the method
`Duration::seconds` to parse the `Max-Age` duration cookie setting. This method
will panic if the value is greater than 2^64/1000 and less than or equal to
2^64, which can result in denial of service for a client or server.

This flaw was corrected by explicitly checking for the `Max-Age` being in this
integer range and clamping the value to the maximum duration value.


Summary: Unchecked vector pre-allocation

Affected versions of this crate pre-allocate memory on deserializing raw
buffers without checking whether there is sufficient data available.

This allows an attacker to do denial-of-service attacks by sending small
msgpack messages that allocate gigabytes of memory.


Summary: lz4-compress is unmaintained

[According to the developers](https://gitlab.redox-os.org/redox-os/tfs/issues/89) this crate is no longer maintained.

The suggested alternative is [`lz4-compression`](https://crates.io/crates/lz4-compression), a maintained fork of `lz4-compress`.

See also [lz-fear](https://crates.io/crates/lz-fear) which is compatible with the reference LZ4 implementation in C, but not with lz4-compress.


Summary: `serial` crate is unmaintained

The [`serial`](https://crates.io/crates/serial) crate is no longer maintained.

Last release was on 2017-07-02.

## Possible alternatives

Consider using an alternative, for instance the blocking librarys:

- [serial2](https://crates.io/crates/serial2)
- [serialport](https://crates.io/crates/serialport)

or async alternatives:

- [mio-serial](https://crates.io/crates/mio-serial)
- [tokio-serial](https://crates.io/crates/tokio-serial)


Summary: An integer underflow could lead to panic

A mistake in error handling in untrusted before 0.6.2 could lead to an integer
underflow and panic if a user of the crate didn't properly check for errors
returned by untrusted.

Combination of these two programming errors (one in untrusted and another by
user of this crate) could lead to a panic and maybe a denial of service of
affected software.

The error in untrusted is fixed in release 0.6.2 released 2018-06-21. It's also
advisable that users of untrusted check for their sources for cases where errors
returned by untrusted are not handled correctly.


Summary: Links in archives can overwrite any existing file

When unpacking a tarball with the `unpack_in`-family of functions it's intended
that only files within the specified directory are able to be written. Tarballs
with hard links or symlinks, however, can be used to overwrite any file on the
filesystem.

Tarballs can contain multiple entries for the same file. A tarball which first
contains an entry for a hard link or symlink pointing to any file on the
filesystem will have the link created, and then afterwards if the same file is
listed in the tarball the hard link will be rewritten and any file can be
rewritten on the filesystem.

This has been fixed in https://github.com/alexcrichton/tar-rs/pull/156 and is
published as `tar` 0.4.16. Thanks to Max Justicz for discovering this and
emailing about the issue!


Summary: Possible double free during unwinding in SmallVec::insert_many

If an iterator passed to `SmallVec::insert_many` panicked in `Iterator::next`,
destructors were run during unwinding while the vector was in an inconsistent
state, possibly causing a double free (a destructor running on two copies of
the same value).

This is fixed in smallvec 0.6.3 by ensuring that the vector's length is not
updated to include moved items until they have been removed from their
original positions.  Items may now be leaked if `Iterator::next` panics, but
they will not be dropped more than once.

Thank you to @Vurich for reporting this bug.


Summary: Malicious input could cause uninitialized memory to be exposed

Affected versions of Claxon made an invalid assumption about the decode buffer
size being a multiple of a value read from the bitstream. This could cause parts
of the decode buffer to not be overwritten. If the decode buffer was newly
allocated and uninitialized, this uninitialized memory could be exposed.

This allows an attacker to observe parts of the uninitialized memory in the
decoded audio stream.

The flaw was corrected by checking that the value read from the bitstream divides
the decode buffer size, and returning a format error if it does not. If an error
is returned, the decode buffer is not exposed. Regression tests and an
additional fuzzer have been added to prevent similar flaws in the future.


Summary: Uncontrolled recursion leads to abort in deserialization

Affected versions of this crate did not properly check for recursion
while deserializing aliases.

This allows an attacker to make a YAML file with an alias referring
to itself causing an abort.

The flaw was corrected by checking the recursion depth.


Affected versions of this crate did not prevent deep recursion while
deserializing data structures.

This allows an attacker to make a YAML file with deeply nested structures
that causes an abort while deserializing it.

The flaw was corrected by checking the recursion depth.

Note: `clap 2.33` is not affected by this because it uses `yaml-rust`
in a way that doesn't trigger the vulnerability. More specifically:

1. The input to the YAML parser is always trusted - is included at compile
time via `include_str!`.

2. The nesting level is never deep enough to trigger the overflow in practice
(at most 5).


Summary: Stack overflow when parsing malicious DNS packet

There's a stack overflow leading to a crash when Trust-DNS's parses a
malicious DNS packet.

Affected versions of this crate did not properly handle parsing of DNS message
compression (RFC1035 section 4.1.4). The parser could be tricked into infinite
loop when a compression offset pointed back to the same domain name to be
parsed.

This allows an attacker to craft a malicious DNS packet which when consumed
with Trust-DNS could cause stack overflow and crash the affected software.

The flaw was corrected by trust-dns-proto 0.4.3 and upcoming 0.5.0 release.


Summary: Bug in SliceDeque::move_head_unchecked allows read of corrupted memory

Affected versions of this crate did not properly update the
head and tail of the deque when inserting and removing elements from the front
if, before insertion or removal, the tail of the deque was in the mirrored
memory region, and if, after insertion or removal, the head of the deque is
exactly at the beginning of the mirrored memory region.

An attacker that controls both element insertion and removal into the deque
could put it in a corrupted state. Once the deque enters such an state, its head
and tail are corrupted, but in bounds of the allocated memory. This can result
in partial reads and writes, reads of uninitialized memory, reads of memory
containing previously dropped objects, etc. An attacker could exploit this to
alter program execution.

The flaw was corrected by properly updating the head and tail of the deque in
this case.


Summary: MsQueue and SegQueue suffer from double-free

Even if an element is popped from a queue, crossbeam would run its
destructor inside the epoch-based garbage collector. This is a source
of double frees.

The flaw was corrected by wrapping elements inside queues in a
`ManuallyDrop`.

Thanks to @c0gent for reporting the issue.


Summary: Use after free in CMS Signing

Affected versions of the OpenSSL crate used structures after they'd been freed.


Summary: Enum repr causing potential memory corruption

The attribute repr() added to enums to be compatible with C-FFI caused
memory corruption on MSVC toolchain.

arrayfire crates <= version 3.5.0 do not have this issue when used with
Rust versions 1.27 or earlier. The issue only started to appear since
Rust version 1.28.

The issue seems to be interlinked with which version of Rust is being used.

The issue was fixed in crate 3.6.0.


Summary: Flaw in streaming state reset() functions can create incorrect results.

Affected versions of this crate did not properly reset a streaming state.

Resetting a streaming state, without finalising it first, creates incorrect results.

The flaw was corrected by not first checking if the state had already been reset, when calling reset().


Summary: Vec-to-vec transmutations could lead to heap overflow/corruption

Affected versions of this crate switched the length and capacity arguments in the Vec::from_raw_parts() constructor,
which could lead to memory corruption or data leakage.

The flaw was corrected by using the constructor correctly.


Summary: chan is end-of-life; use crossbeam-channel instead

**`chan` has reached its end-of-life and is now deprecated.**

The intended successor of this crate is
[`crossbeam-channel`](https://github.com/crossbeam-rs/crossbeam/tree/master/crossbeam-channel).
Its API is strikingly similar, but comes with a much better `select!` macro,
better performance, a better test suite and an all-around better
implementation.


Summary: term is looking for a new maintainer

The author of the `term` crate does not have time to maintain it and is looking
for a new maintainer.

Some maintained alternatives you can potentially switch to instead, depending
on your needs:

- [`crossterm`](https://github.com/crossterm-rs/crossterm)
- [`termcolor`](https://crates.io/crates/termcolor)
- [`yansi`](https://crates.io/crates/yansi)


Summary: quickersort is deprecated and unmaintained

The author of the `quickersort` crate has deprecated it and does not recommend using it anymore.

Everything in it has been incorporated into [std::sort_unstable] in the standard library as of Rust 1.20.

[std::sort_unstable]: https://doc.rust-lang.org/stable/std/primitive.slice.html#method.sort_unstable


Summary: `tempdir` crate has been deprecated; use `tempfile` instead

The [`tempdir`](https://crates.io/crates/tempdir) crate has been deprecated
and the functionality is merged into [`tempfile`](https://crates.io/crates/tempfile).


Summary: smallvec creates uninitialized value of any type

Affected versions of this crate called `mem::uninitialized()` to create values of a user-supplied type `T`.
This is unsound e.g. if `T` is a reference type (which must be non-null and thus may not remain uninitialized).

The flaw was corrected by avoiding the use of `mem::uninitialized()`, using `MaybeUninit` instead.


Summary: Multiple memory safety issues

Affected versions contain multiple memory safety issues, such as:

 - Unsoundly coercing immutable references to mutable references
 - Unsoundly extending lifetimes of strings
 - Adding the `Send` marker trait to objects that cannot be safely sent between threads

This may result in a variety of memory corruption scenarios, most likely use-after-free.

A significant refactoring effort has been conducted to resolve these issues.


Summary: Possible use-after-free with `proplist::Iterator`

Affected versions contained a possible use-after-free issue with property list iteration
due to a lack of a lifetime constraint tying the lifetime of a `proplist::Iterator` to the
`Proplist` object for which it was created. This made it possible for users, without
experiencing a compiler error/warning, to destroy the `Proplist` object before the iterator,
thus destroying the underlying C object the iterator works upon, before the iterator may be
finished with it.

This impacts all versions of the crate before `2.5.0` back to `1.0.5`. Before version
`1.0.5` the function that produces the iterator was broken to the point of being useless.


Summary: Use-after-free with objects returned by `Stream`'s `get_format_info` and `get_context` methods

Affected versions contained a pair of use-after-free issues with the objects returned by the `get_format_info` and `get_context` methods of `Stream` objects. These objects were mistakenly being constructed without setting an important flag to prevent destruction of the underlying C objects they reference upon their own destruction.


Summary: Use of uninitialized memory in temporary

Uninit memory is used as a RNG seed in temporary

The following function is used as a way to get entropy from the system, which does operations on and exposes uninit memory, which is UB.

```rust
fn random_seed(_: &Path, _: &str) -> [u64; 2] {
    use std::mem::uninitialized as rand;
    unsafe { [rand::<u64>() ^ 0x12345678, rand::<u64>() ^ 0x87654321] }
}
```

This has been resolved in the 0.6.4 release.

The crate is not intended to be used outside of a testing environment.

For a general purpose crate to create temporary directories, [`tempfile`](https://crates.io/crates/tempfile) is an alternative for this crate.


Summary: Uncontrolled recursion leads to abort in HTML serialization

Affected versions of this crate did use recursion for serialization of HTML
DOM trees.

This allows an attacker to cause abort due to stack overflow by providing
a pathologically nested input.

The flaw was corrected by serializing the DOM tree iteratively instead.


Summary: Bug in SliceDeque::move_head_unchecked corrupts its memory

Affected versions of this crate entered a corrupted state if
`mem::size_of::<T>() % allocation_granularity() != 0` and a specific allocation
pattern was used: sufficiently shifting the deque elements over the mirrored
page boundary.

This allows an attacker that controls controls both element insertion and
removal to corrupt the deque, such that reading elements from it would read
bytes corresponding to other elements in the deque. (e.g. a read of T could read
some bytes from one value and some bytes from an adjacent one, resulting in a T
whose value representation is not meaningful). This is undefined behavior.

The flaw was corrected by using a pair of pointers to track the head and tail of
the deque instead of a pair of indices. This pair of pointers are represented
using a Rust slice.


Summary: Out of Memory in stream::read_raw_bytes_into()

Affected versions of this crate called Vec::reserve() on user-supplied input.

This allows an attacker to cause an Out of Memory condition while calling the
vulnerable method on untrusted data.


Summary: Failure to properly verify ed25519 signatures makes any signature valid

Affected versions of this crate did not properly verify ed25519 signatures.
Any signature with a correct length was considered valid.

This allows an attacker to impersonate any node identity.


Summary: Format string vulnerabilities in `pancurses`

`pancurses::mvprintw` and `pancurses::printw` passes a pointer from a rust `&str` to C,
allowing hostile input to execute a format string attack, which trivially allows writing
arbitrary data to stack memory.


Summary: Buffer overflow and format vulnerabilities in functions exposed without unsafe

`ncurses` exposes functions from the ncurses library which:

- Pass buffers without length to C functions that may write an arbitrary amount of
  data, leading to a buffer overflow. (`instr`, `mvwinstr`, etc)
- Passes rust &str to strings expecting C format arguments, allowing hostile
  input to execute a format string attack, which trivially allows writing
  arbitrary data to stack memory (functions in the `printw` family).

ncurses::instr ncurses::mvprintw ncurses::mvwinstr ncurses::mvwprintw ncurses::printw


Summary: Processing of maliciously crafted length fields causes memory allocation SIGABRTs

Affected versions of this crate tried to preallocate a vector for an arbitrary amount of bytes announced by the ASN.1-DER length field without further checks.

This allows an attacker to trigger a SIGABRT by creating length fields that announce more bytes than the allocator can provide.

The flaw was corrected by not preallocating memory.


Summary: Flaw in string parsing can lead to crashes due to invalid memory access.

The affected version of this crate did not guard against accessing memory
beyond the range of its input data. A pointer cast to read the data into
a 256-bit register could lead to a segmentation fault when the end plus
the 32 bytes (256 bit) read would overlap into the next page during string
parsing.

```
page   |  ...  page 1  ...  | ... page 2  ... |
data   | x[n * 32 byte]xx__ |                 |
access | ..][ 32 byte ]     |                 |
segflt |               [ 32 | byte ]          |
```

This allows an attacker to eventually crash a service.

The flaw was corrected by using a padding buffer for the last read from the
input. So that we are we never read over the boundary of the input data.


Summary: Double-free and use-after-free in SmallVec::grow()

Attempting to call `grow` on a spilled SmallVec with a value equal to the current capacity causes it to free the existing data. This performs a double free immediately and may lead to use-after-free on subsequent accesses to the SmallVec contents.

An attacker that controls the value passed to `grow` may exploit this flaw to obtain memory contents or gain remote code execution.

Credits to @ehuss for discovering, reporting and fixing the bug.


Summary: MultiDecoder::read() drops uninitialized memory of arbitrary type on panic in client code

Affected versions of libflate have set a field of an internal structure with a generic type to an uninitialized value in `MultiDecoder::read()` and reverted it to the original value after the function completed. However, execution of `MultiDecoder::read()` could be interrupted by a panic in caller-supplied `Read` implementation. This would cause `drop()` to be called on uninitialized memory of a generic type implementing `Read`.

This is equivalent to a use-after-free vulnerability and could allow an attacker to gain arbitrary code execution.

The flaw was corrected by aborting immediately instead of unwinding the stack in case of panic within `MultiDecoder::read()`. The issue was discovered and fixed by Shnatsel.


Summary: Flaw in offset_of and span_of causes SIGILL, drops uninitialized memory of arbitrary type on panic in client code

Affected versions of this crate caused traps and/or memory unsafety by zero-initializing references.
They also could lead to uninitialized memory being dropped if the field for which the offset is requested was behind a deref coercion, and that deref coercion caused a panic.

The flaw was corrected by using `MaybeUninit`.


Summary: Memory corruption in SmallVec::grow()

Attempting to call `grow` on a spilled SmallVec with a value less than the current capacity causes corruption of memory allocator data structures.

An attacker that controls the value passed to `grow` may exploit this flaw to obtain memory contents or gain remote code execution.

Credits to @ehuss for discovering, reporting and fixing the bug.


Summary: Wrong memory orderings in RwLock potentially violates mutual exclusion

Wrong memory orderings inside the RwLock implementation allow for two writers to acquire the lock at the same time. The drop implementation used Ordering::Relaxed, which allows the compiler or CPU to reorder a mutable access on the locked data after the lock has been yielded.

Only users of the RwLock implementation are affected. Users of Once (including users of lazy_static with the `spin_no_std` feature enabled) are NOT affected.

On strongly ordered CPU architectures like x86, the only real way that this would lead to a memory corruption is if the compiler reorders an access after the lock is yielded, which is possible but in practice unlikely. It is a more serious issue on weakly ordered architectures such as ARM which, except in the presence of certain instructions, allow the hardware to decide which accesses are seen at what times. Therefore on an ARM system it is likely that using the wrong memory ordering would result in a memory corruption, even if the compiler itself doesn't reorder the memory accesses in a buggy way.

The flaw was corrected by https://github.com/mvdnes/spin-rs/pull/66.


Summary: Flaw in interface may drop uninitialized instance of arbitrary types

Affected versions of this crate would call `Vec::set_len` on an uninitialized
vector with user-provided type parameter, in an interface of the HDR image
format decoder. They would then also call other code that could panic before
initializing all instances.

This could run Drop implementations on uninitialized types, equivalent to
use-after-free, and allow an attacker arbitrary code execution.

Two different fixes were applied. It is possible to conserve the interface by
ensuring proper initialization before calling `Vec::set_len`. Drop is no longer
called in case of panic, though.

Starting from version `0.22`, a breaking change to the interface requires
callers to pre-allocate the output buffer and pass a mutable slice instead,
avoiding all unsafe code.


Summary: Flaw in generativity allows out-of-bounds access

Affected versions of this crate did not properly implement the generativity,
because the invariant lifetimes were not necessarily `drop`ped.

This allows an attacker to mix up two arenas, using indices created from one
arena with another one. This might lead to an out-of-bounds read or write
access into the memory reserved for the arena.

The flaw was corrected by implementing generativity correctly in version 0.4.0.


Summary: Use-after-free in buffer conversion implementation

The From<Buffer> implementation for Vec<u8> was not properly implemented,
returning a vector backed by freed memory. This could lead to memory corruption
or be exploited to cause undefined behavior.

A fix was published in version 0.1.3.


Summary: Panic during initialization of Lazy<T> might trigger undefined behavior

If during the first dereference of Lazy<T> the initialization function panics,
subsequent dereferences will execute `std::hints::unreachable_unchecked`.

Applications with `panic = "abort"` are not affected, as there will be no
subsequent dereferences.


Summary: Internally mutating methods take immutable ref self

Affected versions of this crate exposed several methods which took `self` by
immutable reference, despite the requesting the RenderDoc API to set a mutable
value internally.

This is technically unsound and calling these methods from multiple threads
without synchronization could lead to unexpected and unpredictable behavior.

The flaw was corrected in release 0.5.0.


Summary: HMAC-BLAKE2 algorithms compute incorrect results

When used in conjunction with the Hash-based Message Authentication Code (HMAC),
the BLAKE2b and BLAKE2s implementations in `blake2` crate versions prior to
v0.8.1 used an incorrect block size (32-bytes instead of 64-bytes for BLAKE2s,
and 64-bytes instead of 128-bytes for BLAKE2b), causing them to miscompute the
`MacResult`.

The v0.8.1 release of the `blake2` crate uses the correct block sizes.

Note that this advisory only impacts usage of BLAKE2 with HMAC, and does not
impact `Digest` functionality.


Summary: fix unsound APIs that could lead to UB

Affected versions of this crate API could use uninitialized memory with some APIs in special
cases, like use the API in none generator context. This could lead to UB.
The flaw was corrected by <https://github.com/Xudong-Huang/generator-rs/issues/9>
                          <https://github.com/Xudong-Huang/generator-rs/issues/11>
                          <https://github.com/Xudong-Huang/generator-rs/issues/13>
                          <https://github.com/Xudong-Huang/generator-rs/issues/14>
This patch fixes all those issues above.


Summary: `Matrix::zip_elements` causes double free

Affected versions of this crate did not properly implements the `Matrix::zip_elements` method, which causes an double free when the given trait implementation might panic.

This allows an attacker to corrupt or take control of the memory.

The flaw was corrected by Phosphorus15.


Summary: Stream callback function is not unwind safe

Affected versions of this crate is not panic safe within callback functions `stream_callback` and `stream_finished_callback`.

The call to user-provided closure might panic before a `mem::forget` call, which then causes a use after free that grants attacker to control the callback function pointer.

This allows an attacker to construct an arbitrary code execution .

The flaw was reported by Phosphorus15.


Summary: Cloned interners may read already dropped strings

Affected versions of this crate did not clone contained strings when an interner is cloned.
Interners have raw pointers to the contained strings, and they keep pointing the strings which the old interner owns, after the interner is cloned.
If a new cloned interner is alive and the old original interner is dead, the new interner has dangling pointers to the old interner's storage, which is already dropped.

This allows an attacker to read the already freed memory.
The dangling pointers are used by the interners to check a string is already interned.
An attacker can do brute force attack to get the data pointed by the dangling pointer.

The flaw was corrected by <https://github.com/Robbepop/string-interner/pull/10>.
This patch implements `Clone` manually to the interner type, so that the internal raw pointers always point the strings owned by the same interner.

PR #10 was also backported to the 0.6 release line in
<https://github.com/Robbepop/string-interner/pull/14> and was released in 0.6.4.


Summary: Test advisory with associated example crate

This is a test advisory useful for verifying RustSec tooling and vulnerability
detection pipelines are working correctly. Aside from the fact that it is filed
against an example crate, it is otherwise considered by the Advisory Database
itself to be a normal security advisory.

It's filed against `rustsec-example-crate`, an otherwise completely empty crate
with no functionality or code, which has three releases:

- [v0.0.0] - *unaffected* by this advisory (but *yanked* from crates.io)
- [v0.0.1] - *vulnerable* according to this advisory
- [v1.0.0] - *patched* by this advisory

[v0.0.0]: https://crates.io/crates/rustsec-example-crate/0.0.0
[v0.0.1]: https://crates.io/crates/rustsec-example-crate/0.0.1
[v1.0.0]: https://crates.io/crates/rustsec-example-crate/1.0.0


Summary: Flaw in CBOR deserializer allows stack overflow

Affected versions of this crate did not properly check if semantic tags were nested excessively during deserialization.

This allows an attacker to craft small (< 1 kB) CBOR documents that cause a stack overflow.

The flaw was corrected by limiting the allowed number of nested tags.


Summary: generichash::Digest::eq always return true

PartialEq implementation for generichash::Digest has compared itself to itself.

Digest::eq always returns true and Digest::ne always returns false.


Summary: Flaw in Scalar::check_overflow allows side-channel timing attack

Versions of `libsecp256k1` prior to `0.3.1` did not execute
Scalar::check_overflow in constant time.

This allows an attacker to potentially leak information via a timing attack.

The flaw was corrected by modifying Scalar::check_overflow to execute in
constant time.


Summary: Unsound `impl Follow for bool`

The implementation of `impl Follow for bool` allows to reinterpret arbitrary bytes as a `bool`.

In Rust `bool` has stringent requirements for its in-memory representation. Use of this function
allows to violate these requirements and invoke undefined behaviour in safe code.


Summary: ChaCha20 counter overflow can expose repetitions in the keystream

The ChaCha20 stream cipher can produce a maximum of 2^32 blocks (~256GB)
before the 32-bit counter overflows. Releases of the `chacha20` crate prior
to v0.2.3 allow generating keystreams larger than this, including seeking
past the limit. When this occurs, the keystream is duplicated, with failure
modes similar to nonce reuse (i.e. exposure of the XOR of two plaintexts).

The v0.2.3 release now panics in this event, rather than exposing the
duplicated keystream. Note this is a "hot fix" solution to the problem
and future releases will pursue returning an error in this case.

Users of the `chacha20poly1305` crate are unaffected by this as this crate
properly asserts the length of the plaintext is less than the maximum allowed
(`P_MAX` as described in RFC 8439 Section 2.8).


Summary: Incorrect implementation of the Streebog hash functions

Internal `update-sigma` function was implemented incorrectly and depending on
`debug-assertions` it could've caused an incorrect result or panic for certain
inputs.


Summary: spin is no longer actively maintained

The author of the `spin` crate does not have time or interest to maintain it.

Consider the following alternatives (all of which support `no_std`):

- [`conquer-once`](https://github.com/oliver-giersch/conquer-once)
- [`lock_api`](https://crates.io/crates/lock_api) (a subproject of `parking_lot`)
  - [`spinning_top`](https://github.com/rust-osdev/spinning_top) spinlock crate built on `lock_api`
- [`spinning`](https://github.com/4lDO2/spinning-rs)


Summary: crust repo has been archived; use libp2p instead

** The `crust` crate repo was archived with no warning or explanation.**

Given that it was archived with no warning or successor, there's not an
official replacement but [`rust-libp2p`](https://github.com/libp2p/rust-libp2p)
looks like it's got a similar feature set and is actively maintained.


Summary: Integer Overflow in HeaderMap::reserve() can cause Denial of Service

`HeaderMap::reserve()` used `usize::next_power_of_two()` to calculate the increased capacity.
However, `next_power_of_two()` silently overflows to 0 if given a sufficiently large number
in release mode.

If the map was not empty when the overflow happens,
the library will invoke `self.grow(0)` and start infinite probing.
This allows an attacker who controls the argument to `reserve()`
to cause a potential denial of service (DoS).

The flaw was corrected in 0.1.20 release of `http` crate.


Summary: HeaderMap::Drain API is unsound

Affected versions of this crate incorrectly used raw pointer,
which introduced unsoundness in its public safe API.

[Failing to drop the Drain struct causes double-free](https://github.com/hyperium/http/issues/354),
and [it is possible to violate Rust's alias rule and cause data race with Drain's Iterator implementation](https://github.com/hyperium/http/issues/355).

The flaw was corrected in 0.1.20 release of `http` crate.


Summary: Unaligned memory access

Affected versions of this crate violated alignment when casting byte slices to
integer slices, resulting in undefined behavior.

The flaw was corrected by Ralf Jung and Diggory Hardy.


Summary: Type confusion if __private_get_type_id__ is overridden

Safe Rust code can implement malfunctioning `__private_get_type_id__` and cause
type confusion when downcasting, which is an undefined behavior.

Users who derive `Fail` trait are not affected.


Summary: Compiler optimisation for next_with_timeout in pnet::transport::IcmpTransportChannelIterator flaws to SEGFAULT

Affected versions of this crate were optimized out by compiler,
which caused dereference of uninitialized file descriptor which caused segfault.


Summary: Fix for UB in failure to catch panics crossing FFI boundaries

Affected versions of this crate failed to catch panics crossing FFI boundaries via callbacks, which
is a form of UB. This flaw was corrected by [this commit][1] which was included in version 2.6.0.

[1]: https://github.com/jnqnfe/pulse-binding-rust/commit/7fd282aef7787577c385aed88cb25d004b85f494


Summary: typemap is Unmaintained

The maintainer seems unreachable.

The crate may or may not be usable as-is despite no maintenance and may not work in future versions of Rust.

The last release seems to have been seven years ago.

## Possible Alternative(s)

 The below list has not been vetted in any way and may or may not contain alternatives;

 - [ttmap](https://crates.io/crates/ttmap)
 - [typemap_rev](https://crates.io/crates/typemap_rev)
 - [typemap-ors](https://crates.io/crates/typemap-ors)


Summary: `boxfnonce` obsolete with release of Rust 1.35.0

[This](https://github.com/stbuehler/rust-boxfnonce/commit/058ac7e1a7d732076da9d8a37baa66bcb67758d8) commit marks the `boxfnonce` crate as obsolete and the GitHub repo has since been archived.

The functionality of `boxfnonce` has been added to Rust since 1.35.0. Use `Box<dyn FnOnce(...) -> ...>`.


Summary: Stack overflow when resolving additional records from MX or SRV null targets

There's a stack overflow leading to a crash and potential DOS when processing
additional records for return of MX or SRV record types from the server.

This is only possible when a zone is configured with a null target for MX or SRV records, i.e. '.'.

Example effected zone record:
```text
no-service 86400 IN MX 0 .
```

Prior to 0.16.0 the additional record processing was not supported by trust-dns-server. There
Are no known issues with upgrading from 0.16 or 0.17 to 0.18.1. The remidy should be to upgrade to
0.18.1. If unable to do so, MX, SRV or other record types with a target to the null type, should be avoided.


Summary: Parsing a specially crafted message can result in a stack overflow

Affected versions of this crate contained a bug in which decoding untrusted
input could overflow the stack.

On architectures with stack probes (like x86), this can be used for denial of
service attacks, while on architectures without stack probes (like ARM)
overflowing the stack is unsound and can result in potential memory corruption
(or even RCE).

The flaw was quickly corrected by @danburkert and released in version 0.6.1.


Summary: rust_sodium is unmaintained; switch to a modern alternative

The `rust_sodium` crate is no longer maintained by its current owner, who
advise in the repository readme that they are looking for
someone else to take ownership of it.

We recommend you switch to an alternative crate such as:
- [`sodiumoxide`](https://crates.io/crates/sodiumoxide)


Summary: sigstack allocation bug can cause memory corruption or leak

An embedding using affected versions of lucet-runtime configured to use
non-default Wasm globals sizes of more than 4KiB, or compiled in debug mode
without optimizations, could leak data from the signal handler stack to guest
programs. This can potentially cause data from the embedding host to leak to
guest programs or cause corruption of guest program memory.

This flaw was resolved by correcting the sigstack allocation logic.


Summary: CBox API allows to de-reference raw pointers without `unsafe` code

`CBox` and `CSemiBox` are part of the public API of the cbox crate
and they allow to create smart pointers from raw pointers and de-reference
them without the need of `unsafe` code.


Summary: Flaw in `realloc` allows reading unknown memory

When `realloc`ing, if we allocate new space, we need to copy the old
allocation's bytes into the new space. There are `old_size` number of bytes in
the old allocation, but we were accidentally copying `new_size` number of bytes,
which could lead to copying bytes into the realloc'd space from past the chunk
that we're bump allocating out of, from unknown memory.

If an attacker can cause `realloc`s, and can read the `realoc`ed data back,
this could allow them to read things from other regions of memory that they
shouldn't be able to. For example, if some crypto keys happened to live in
memory right after a chunk we were bump allocating out of, this could allow
the attacker to read the crypto keys.

Beyond just fixing the bug and adding a regression test, I've also taken two
additional steps:

1. While we were already running the testsuite under `valgrind` in CI, because
   `valgrind` exits with the same code that the program did, if there are
   invalid reads/writes that happen not to trigger a segfault, the program can
   still exit OK and we will be none the wiser. I've enabled the
   `--error-exitcode=1` flag for `valgrind` in CI so that tests eagerly fail
   in these scenarios.

2. I've written a quickcheck test to exercise `realloc`. Without the bug fix
   in this patch, this quickcheck immediately triggers invalid reads when run
   under `valgrind`. We didn't previously have quickchecks that exercised
   `realloc` because `realloc` isn't publicly exposed directly, and instead
   can only be indirectly called. This new quickcheck test exercises `realloc`
   via `bumpalo::collections::Vec::resize` and
   `bumpalo::collections::Vec::shrink_to_fit` calls.


Summary: use-after or double free of allocated memory

Conversion of `BitVec` to `BitBox` did not account for allocation movement.

The flaw was corrected by using the address after resizing, rather than the original base address.


Summary: Flaw in hyper allows request smuggling by sending a body in GET requests

Vulnerable versions of hyper allow GET requests to have bodies, even if there is
no Transfer-Encoding or Content-Length header.  As per the HTTP 1.1
specification, such requests do not have bodies, so the body will be interpreted
as a separate HTTP request.

This allows an attacker who can control the body and method of an HTTP request
made by hyper to inject a request with headers that would not otherwise be
allowed, as demonstrated by sending a malformed HTTP request from a Substrate
runtime.  This allows bypassing CORS restrictions.  In combination with other
vulnerabilities, such as an exploitable web server listening on loopback, it may
allow remote code execution.

The flaw was corrected in hyper version 0.12.34.


Summary: `read_scalar` and `read_scalar_at` allow transmuting values without `unsafe` blocks

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


Summary: tiberius is unmaintained

The author of `tiberius` has archived the GitHub repository and left the
following note:

> I do not have the time to overhaul the library and do not intend to further
> maintain the 0.3 version relying on the old futures ecosystem.

Suggested alternatives are:

- [`odbc`](https://crates.io/crates/odbc)
- [`sqlx`](https://github.com/launchbadge/sqlx/issues/116) (forthcoming)


Summary: Library exclusively intended to obfuscate code.

This crate allows you to write safe functions with unsafe bodies without the `unsafe` keyword.

The value this adds is questionable, and hides `unsafe` usages from naive analysis.


Summary: Relies on undefined behavior of `char::from_u32_unchecked`

The Windows implementation of this crate relied on the behavior of
`std::char::from_u32_unchecked` when its safety clause is violated.
Even though this worked with Rust versions up to 1.42 (at least),
that behavior could change with any new Rust version, possibly leading
a security issue.

The flaw was corrected in version 2.0.0.


Summary: fake-static allows converting any reference into a `'static` reference

fake-static allows converting a reference with any lifetime into
a reference with `'static` lifetime without the `unsafe` keyword.

Internally, this crate does not use unsafe code, it instead
exploits a soundness bug in rustc:

https://github.com/rust-lang/rust/issues/25860


Summary: Various memory safety issues

Several memory safety issues have been uncovered in an audit of
rusqlite.

See https://github.com/rusqlite/rusqlite/releases/tag/0.23.0 for a complete list.


Summary: Crash causing Denial of Service attack

Server or client applications that call the SSL_check_chain() function during or after a TLS 1.3
handshake may crash due to a NULL pointer dereference as a result of incorrect handling of the
"signature_algorithms_cert" TLS extension. The crash occurs if an invalid or unrecognised signature
algorithm is received from the peer. This could be exploited by a malicious peer in a Denial of
Service attack.


Summary: `net2` crate has been deprecated; use `socket2` instead

The [`net2`](https://crates.io/crates/net2) crate has been deprecated
and users are encouraged to considered [`socket2`](https://crates.io/crates/socket2) instead.


Summary: Use after free in ArcIntern::drop

`ArcIntern::drop` has a race condition where it can release memory
which is about to get another user. The new user will get a reference
to freed memory.

This was fixed by serializing access to an interned object while it
is being deallocated.

Versions prior to 0.3.12 used stronger locking which avoided the problem.


Summary: crate has been renamed to `block-cipher`

This crate has been renamed from `block-cipher-trait` to `block-cipher`.

The new repository location is at:

<https://github.com/RustCrypto/traits/tree/master/block-cipher>


Summary: tokio-rustls reads may cause excessive memory usage

`tokio-rustls` does not call `process_new_packets` immediately after `read`,
so the expected termination condition `wants_read` always returns true.
As long as new incoming data arrives faster than it is processed
and the reader does not return pending, data will be buffered.

This may cause DoS.


Summary: `stb_truetype` crate has been deprecated; use `ttf-parser` instead

This crate was maintained for use in rusttype which has switched to use [ttf-parser](https://crates.io/crates/ttf-parser)


Summary: rio allows a use-after-free buffer access when a future is leaked

When a `rio::Completion` is leaked, its drop code will not run. The drop code
is responsible for waiting until the kernel completes the I/O operation into, or
out of, the buffer borrowed by `rio::Completion`. Leaking the struct will allow
one to access and/or drop the buffer, which can lead to a use-after-free,
data races or leaking secrets.

Upstream is not interested in fixing the issue.


Ozone contains several memory safety issues including [out-of-bound access](https://github.com/bqv/ozone/blob/e21f948b0178ab305f644118f18d87a838c618e0/src/buffer.rs#L38-L48)
and dropping of [uninitialized memory](https://github.com/bqv/ozone/blob/e21f948b0178ab305f644118f18d87a838c618e0/src/map.rs#L94-L101).


Summary: Lifetime boundary for `raw_slice` and `raw_slice_mut` are incorrect

The affected version of `rulinalg` has incorrect lifetime boundary definitions
for `RowMut::raw_slice` and `RowMut::raw_slice_mut`. They do not conform with
Rust's borrowing rule and allows the user to create multiple mutable references
to the same location. This may result in unexpected calculation result and data
race if both references are used at the same time.


Summary: Improper uniqueness verification of signature threshold

The tough library, prior to 0.7.1, does not properly verify the uniqueness of
keys in the signatures provided to meet the threshold of cryptographic
signatures. It allows someone with access to a valid signing key to create
multiple valid signatures in order to circumvent TUF requiring a minimum
threshold of unique keys before the metadata is considered valid.

AWS would like to thank Erick Tryzelaar of the Google Fuchsia Team for
reporting this issue.

A fix is available in version 0.7.1.

CVE-2020-6174 is assigned to the same issue in the TUF reference
implementation.

If you have any questions or comments about this advisory, contact AWS Security
at aws-security@amazon.com.


Summary: bigint is unmaintained, use uint instead

The `bigint` crate is not maintained any more and contains several known bugs (including a soundness bug);
use [`uint`](https://crates.io/crates/uint) instead.


Summary: linked-hash-map creates uninitialized NonNull pointer

Affected versions of this crate called `mem::uninitialized()` to create a `NonNull<T>`,
which is undefined behavior.

The flaw was corrected by avoiding the use of `mem::uninitialized()`.


Summary: traitobject assumes the layout of fat pointers

This crate gets the data pointer from fat pointers assuming that the first
element in a fat pointer is the data pointer. This is currently true, but
it may change in a future Rust version, leading to memory corruption.

This has been fixed in the master branch of the crate, but is has not
been released into crates.io.


Summary: `LocalRequest::clone` creates multiple mutable references to the same object

The affected version of `rocket` contains a `Clone` trait implementation of
`LocalRequest` that reuses the pointer to inner `Request` object.
This causes data race in rare combinations of APIs if the original and the
cloned objects are modified at the same time.


Summary: Allows viewing and modifying arbitrary structs as bytes

Affected versions of rgb crate allow viewing and modifying data of any type `T` wrapped in `RGB<T>` as bytes,
and do not correctly constrain `RGB<T>` and other wrapper structures to the types for which it is safe to do so.

Safety violation possible for a type wrapped in `RGB<T>` and similar wrapper structures:

 * If `T` contains padding, viewing it as bytes may lead to exposure of contents of uninitialized memory.
 * If `T` contains a pointer, modifying it as bytes may lead to dereferencing of arbitrary pointers.
 * Any safety and/or validity invariants for `T` may be violated.

The issue was resolved by requiring all types wrapped in structures provided by RGB crate to implement an unsafe marker trait.


Summary: Missing sanitization in mozwire allows local file overwrite of files ending in .conf

The client software downloaded a list of servers from mozilla's servers and created local files named
after the hostname field in the json document.

No verification of the content of the string was made, and it could therefore have included '../' leading to path traversal.

This allows an attacker in control of mozilla's servers to overwrite/create local files named .conf.

The flaw was corrected by sanitizing the hostname field.


Summary: HTTP Request smuggling through malformed Transfer Encoding headers

HTTP pipelining issues and request smuggling attacks are possible due to incorrect
Transfer encoding header parsing.

It is possible conduct HTTP request smuggling attacks (CL:TE/TE:TE) by sending invalid Transfer Encoding headers.

By manipulating the HTTP response the attacker could poison a web-cache, perform an XSS attack, or obtain sensitive information
from requests other than their own.


Summary: StrcCtx deallocates a memory region that it doesn't own

`StrcCtx` deallocate a memory region that it doesn't own when `StrcCtx` is created without using `StrcCtx::new`.
This can introduce memory safety issues such as double-free and use-after-free to client programs.


Summary: Matrix::new() drops uninitialized memory

`Matrix::new()` internally calls `Matrix::fill_with()` which uses `*ptr = value` pattern to initialize the buffer.
This pattern assumes that there is an initialized struct at the address and drops it, which results in dropping of uninitialized struct.


Summary: Multiple security issues including data race, buffer overflow, and uninitialized memory drop

`arr` crate contains multiple security issues. Specifically,

1. It incorrectly implements Sync/Send bounds, which allows to smuggle non-Sync/Send types across the thread boundary.
2. `Index` and `IndexMut` implementation does not check the array bound.
3. `Array::new_from_template()` drops uninitialized memory.


Summary: Chunk API does not respect align requirement

Chunk API does not respect the align requirement of types. Unaligned reference can be created with the API, which is an undefined behavior.


Summary: failure is officially deprecated/unmaintained

The `failure` crate is officially end-of-life: it has been marked as deprecated
by the former maintainer, who has announced that there will be no updates or
maintenance work on it going forward.

The following are some suggested actively developed alternatives to switch to:

- [`anyhow`](https://crates.io/crates/anyhow)
- [`eyre`](https://crates.io/crates/eyre)
- [`fehler`](https://crates.io/crates/fehler)
- [`snafu`](https://crates.io/crates/snafu)
- [`thiserror`](https://crates.io/crates/thiserror)


Summary: Misbehaving `HandleLike` implementation can lead to memory safety violation

Unsafe code in `ObjectPool` has time-of-check to time-of-use (TOCTOU) bug that
can eventually lead to a memory safety violation. `ObjectPool` and `HandlePool`
implicitly assumes that `HandleLike` trait methods are pure, i.e., they always
return the same value. However, this assumption is unsound since `HandleLike`
is a safe, public trait that allows a custom implementation.


Summary: Memory safety issues in `compact::Vec`

`compact::Vec` contains multiple memory safety issues.

1. It mishandles large capacity and causes out-of-bound access in 32-bit / allocator layout mismatch in 64-bit.
2. `remove()` is not panic-safe and causes double-free when an index larger than the length is provided.


Summary: `index()` allows out-of-bound read and `remove()` has off-by-one error

`Slab::index()` does not perform the boundary checking, which leads to out-of-bound read access. `Slab::remove()` copies an element from an invalid address due to off-by-one error, resulting in memory leakage and uninitialized memory drop.


Summary: Obstack generates unaligned references

Obstack generates unaligned references for types that require a large alignment.


Summary: 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<InlineArray<A, T>>`.
* `Clone` and `insert_from` are not panic-safe; A panicking iterator causes memory safety issues with them.

InlineArray:

* Generates unaligned references for types with a large alignment requirement.


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


Summary: 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 the [`parity-ws` fork](https://crates.io/crates/parity-ws) (>=0.10.0) by [disconnecting a client when the buffer runs full](https://github.com/housleyjk/ws-rs/pull/328).


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


Summary: bespoke Cell implementation allows obtaining several mutable references to the same data

The custom implementation of a Cell primitive in the affected versions of this crate
does not keep track of mutable references to the underlying data.

This allows obtaining several mutable references to the same object
which may result in arbitrary memory corruption, most likely use-after-free.

The flaw was corrected by switching from a bespoke `Cell<T>` implementation to `Rc<RefCell<T>>`.


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

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


Summary: Use-after-free in BodyStream due to lack of pinning

Affected versions of this crate did not require the buffer wrapped in `BodyStream` to be pinned,
but treated it as if it had a fixed location in memory. This may result in a use-after-free.

The flaw was corrected by making the trait `MessageBody` require `Unpin`
and making `poll_next()` function accept `Pin<&mut Self>` instead of `&mut self`.


Summary: Use-after-free in Framed due to lack of pinning

Affected versions of this crate did not require the buffer wrapped in `Framed` to be pinned,
but treated it as if it had a fixed location in memory. This may result in a use-after-free.

The flaw was corrected by making the affected functions accept `Pin<&mut Self>` instead of `&mut self`.


Summary: 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<u8>` with a custom managed
pointer.  Elements are now stored and retrieved using types with proper alignment corresponding to
original types.


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


Summary: Undefined Behavior in bounded channel

The affected version of this crate's the `bounded` channel incorrectly assumes that `Vec::from_iter` has allocated capacity that same as the number of iterator elements. `Vec::from_iter` does not actually guarantee that and may allocate extra memory. The destructor of the `bounded` channel reconstructs `Vec` from the raw pointer based on the incorrect assumes described above. This is unsound and causing deallocation with the incorrect capacity when `Vec::from_iter` has allocated different sizes with the number of iterator elements.


Summary: dirs is unmaintained, use dirs-next instead

The `dirs` crate is not maintained any more;
use [`dirs-next`](https://crates.io/crates/dirs-next) instead.


Summary: directories is unmaintained, use directories-next instead

The `directories` crate is not maintained any more;
use [`directories-next`](https://crates.io/crates/directories-next) instead.


Summary: Please see RUSTSEC-2018-0020

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


Summary: stdweb is unmaintained

The author of the `stdweb` crate is unresponsive.

Maintained alternatives:

- [`wasm-bindgen`](https://github.com/rustwasm/wasm-bindgen)
- [`js-sys`](https://github.com/rustwasm/wasm-bindgen/tree/master/crates/js-sys)
- [`web-sys`](https://github.com/rustwasm/wasm-bindgen/tree/master/crates/web-sys)


Summary: crate has been renamed to `cipher`

This crate has been renamed from `block-cipher` to `cipher`.

The new repository location is at:

<https://github.com/RustCrypto/traits/tree/master/cipher>


Summary: crate has been renamed to `cipher`

This crate has been renamed from `stream-cipher` to `cipher`.

The new repository location is at:

<https://github.com/RustCrypto/traits/tree/master/cipher>


Summary: 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 fixed by fixing `Send` and `Sync` implementations, and by adding a `PhantomData<&'a mut U>` marker to the `MappedMutexGuard` type to tell the compiler that the guard is over
U too.


Summary: futures_task::waker may cause a use-after-free if used on a type that isn't 'static

Affected versions of the crate did not properly implement a `'static` lifetime bound on the `waker` function.
This resulted in a use-after-free if `Waker::wake()` is called after original data had been dropped.

The flaw was corrected by adding `'static` lifetime bound to the data `waker` takes.


Summary: futures_task::noop_waker_ref can segfault due to dereferencing a NULL pointer

Affected versions of the crate used a `UnsafeCell` in thread-local storage to return a noop waker reference,
assuming that the reference would never be returned from another thread.

This resulted in a segmentation fault crash if `Waker::wake_by_ref()` was called on a waker returned from another thread due to
it attempting to dereference a pointer that wasn't accessible from the main thread.

Reproduction Example (from issue):
```rust
use futures_task::noop_waker_ref;
fn main() {
    let waker = std::thread::spawn(|| noop_waker_ref()).join().unwrap();
    waker.wake_by_ref();
}
```

The flaw was corrected by using a `OnceCell::Lazy<>` wrapper around the noop waker instead of thread-local storage.


Summary: Improper `Sync` implementation on `FuturesUnordered` in futures-utils can cause data corruption

Affected versions of the crate had an unsound `Sync` implementation on the `FuturesUnordered` structure, which used a `Cell` for
interior mutability without any code to handle synchronized access to the underlying task list's length and head safely.

This could of lead to data corruption since two threads modifying the list at once could see incorrect values due to the lack
of access synchronization.

The issue was fixed by adding access synchronization code around insertion of tasks into the list.


Summary: crate has been renamed to `safe-nd`

This crate has been renamed from `safe-nd` to `sn_data_types`.

The new repository location is:

<https://github.com/maidsafe/sn_data_types>


Summary: crate has been renamed to `sn_ffi_utils`

This crate has been renamed from `ffi_utils` to `sn_ffi_utils`.

The new repository location is:

<https://github.com/maidsafe/sn_ffi_utils>


Summary: crate has been renamed to `sn_fake_clock`

This crate has been renamed from `fake_clock` to `sn_fake_clock`.

The new repository location is:

<https://github.com/maidsafe/sn_fake_clock>


Summary: crate has been renamed to `sn_bindgen`

This crate has been renamed from `safe_bindgen` to `sn_bindgen`.

The new repository location is:

<https://github.com/maidsafe/sn_bindgen>


Summary: crate has been renamed to `qp2p`

This crate has been renamed from `quic-p2p` to `qp2p`.

The new repository location is:

<https://github.com/maidsafe/qp2p>


Summary: Unexpected panic in multihash `from_slice` parsing code

In versions prior 0.11.3 it's possible to make `from_slice` panic by feeding it certain malformed input.
It's never documented that `from_slice` (and `from_bytes` which wraps it) can panic, and its' return type (`Result<Self, DecodeError>`) suggests otherwise.

In practice, `from_slice`/`from_bytes` is frequently used in networking code (for example [in rust-libp2p](https://github.com/libp2p/rust-libp2p/blob/7b415d5e7040e45c541f76f2c409e63d4d3249c6/core/src/peer_id.rs#L89)) and is being called with unsanitized data from untrusted sources.
This can allow attackers to cause DoS by causing an unexpected `panic` in the network client's code.


Summary: 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 email data into arbitrary files (using sendmail's
logging features).

The flaw is corrected by modifying the executed command to stop parsing arguments
before passing the destination addresses.

NOTE: This vulnerability only affects the `sendmail` transport. Others, including `smtp`, are not
affected.

This vulnerability was reported by vin01.


Summary: Some lock_api lock guard objects can cause data races

Affected versions of lock_api 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 thread boundaries in safe Rust code.

This issue was fixed by changing the trait bounds on the `Mapped` guard types
and removing the `Sync` trait for the `RwLock` guards.


Summary: 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 functions. This may occur without the user's knowledge, notably in the Rust standard library or third-party libraries.

The affected functions from time 0.2.7 through 0.2.22 are:

- `time::UtcOffset::local_offset_at`
- `time::UtcOffset::try_local_offset_at`
- `time::UtcOffset::current_local_offset`
- `time::UtcOffset::try_current_local_offset`
- `time::OffsetDateTime::now_local`
- `time::OffsetDateTime::try_now_local`

The affected functions in time 0.1 (all versions) are:

- `time::at_utc`
- `time::at`
- `time::now`
- `time::tzset`

Non-Unix targets (including Windows and wasm) are unaffected.

### Patches

Pending a proper fix, the internal method that determines the local offset has been modified to always return `None` on the affected operating systems. This has the effect of returning an `Err` on the `try_*` methods and `UTC` on the non-`try_*` methods.

Users and library authors with time in their dependency tree should perform `cargo update`, which will pull in the updated, unaffected code.

Users of time 0.1 do not have a patch and should upgrade to an unaffected version: time 0.2.23 or greater or the 0.3 series.

### Workarounds

A possible workaround for crates affected through the transitive dependency in `chrono`, is to avoid using the default `oldtime` feature dependency of the `chrono` crate by disabling its `default-features` and manually specifying the required features instead.

#### Examples:

`Cargo.toml`:

```toml
chrono = { version = "0.4", default-features = false, features = ["serde"] }
```

```toml
chrono = { version = "0.4.22", default-features = false, features = ["clock"] }
```

Commandline:

```bash
cargo add chrono --no-default-features -F clock
```

Sources:
 - [chronotope/chrono#602 (comment)](https://github.com/chronotope/chrono/issues/602#issuecomment-1242149249)
 - [vityafx/serde-aux#21](https://github.com/vityafx/serde-aux/issues/21)

linux redox solaris android ios macos netbsd openbsd freebsd


Summary: GenericMutexGuard allows data races of non-Sync types across threads

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

This is a soundness issue and allows data races, potentially leading to crashes
and segfaults from safe Rust code.

The flaw was corrected by adding a `T: Send + Sync` bound for
`GenericMutexGuard`'s `Sync` trait.

This bug is [similar to one](https://github.com/rust-lang/rust/issues/41622) in
`std::sync::Mutex`.


Summary: Mutable reference with immutable provenance

A mutable reference to a struct was constructed by dereferencing a pointer
obtained from `slice::as_ptr`. Instead, `slice::as_mut_ptr` 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
derived pointer.

There is no evidence for miscompilation, exploitable or otherwise, caused by
this bug. [Further investigation on Zulip][Zulip] suggests that the unoptimized
generated LLVM IR does not contain any UB itself, effectively mitigating
further effects.

[Zulip]: https://rust-lang.zulipchat.com/#narrow/stream/146229-wg-secure-code/topic/Implications.20of.20using.20.60slice.3A.3Aas_ptr.60.20for.20mutable.20access/near/216499472


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

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


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


Summary: crate has been renamed to `sn_routing`

This crate has been renamed from `routing` to `sn_routing`.

The new repository location is:

<https://github.com/maidsafe/sn_routing>


Summary: memmap is unmaintained

The author of the `memmap` crate is unresponsive.

Maintained alternatives:

- [`memmap2`](https://github.com/RazrFalcon/memmap2-rs)


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

The [`net2`](https://crates.io/crates/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 memory
layout, and this will cause invalid memory access if the standard library
changes the implementation. No warnings or errors will be emitted once the
change happens.


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

The [`socket2`](https://crates.io/crates/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 memory
layout, and this will cause invalid memory access if the standard library
changes the implementation. No warnings or errors will be emitted once the
change happens.


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

The [`miow`](https://crates.io/crates/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 memory
layout, and this will cause invalid memory access if the standard library
changes the implementation. No warnings or errors will be emitted once the
change happens.


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

The [`mio`](https://crates.io/crates/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 memory
layout, and this will cause invalid memory access if the standard library
changes the implementation. No warnings or errors will be emitted once the
change happens.


Summary: ordered_float:NotNan may contain NaN after panic in assignment operators

After using an assignment operators such as `NotNan::add_assign`, `NotNan::mul_assign`, 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 never `NaN`.  (It could also cause undefined behavior in third-party unsafe code that makes the same assumption, as well as logic errors in safe code.)

This was mitigated starting in version 0.4.0, by panicking if the assigned value is NaN.  However, in affected versions from 0.4.0 onward, code that uses the `NotNan` value during unwinding, or that continues after catching the panic, could still observe the invalid value and trigger undefined behavior.

The flaw is fully corrected in versions 1.1.1 and 2.0.1, by ensuring that the assignment operators panic without modifying the operand, if the result would be `NaN`.


This crate has been superseded by `sn_client`.

The new repository location is:

<https://github.com/maidsafe/sn_client>


Summary: crate has been renamed to `sn_node`

This crate has been renamed from `safe_vault` to `sn_node`.

The new repository location is:

<https://github.com/maidsafe/sn_node>


Summary: crate has been renamed to `sn_client`

This crate has been renamed from `safe_core` to `sn_client`.

The new repository location is:

<https://github.com/maidsafe/sn_client>


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

Affected versions of this crate unconditionally implemented Sync trait for `TryMutex<T>` 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 implementation.


Summary: 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 to affected Sync/Send trait implementations.


Summary: 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 cryptographically secure `ChaCha` random
number generator..


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

`thex::Thex<T>` 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.


Summary: Dangling reference in `access::Map` with Constant

Using the `arc_swap::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 performance.


Summary: 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<K, V>` 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 affected `Send`/`Sync` trait implementations.


Summary: 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 that offset into the body.

One way to exploit this vulnerability would be for an adversary to craft a request such that the body contains a request that would not be noticed by a reverse proxy, allowing it to forge forwarded/x-forwarded headers. If an application trusted the authenticity of these headers, it could be misled by the smuggled request.

Another potential concern with this vulnerability is that if a reverse proxy is sending multiple http clients' requests along the same keep-alive connection, it would be possible for the smuggled request to specify a long content and capture another user's request in its body. This content could be captured in a post request to an endpoint that allows the content to be subsequently retrieved by the adversary.

The flaw was corrected in commit [7df79f](https://github.com/http-rs/async-h1/commit/7df79f1d5d99fc0f492b315eebc7f0d301a85212) by ensuring that the request body is always consumed from the tcp stream before attempting to read subsequent keep-alive request headers from it.


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

`ARefss<'a, V>` 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<'a, V>`.

By using the `ARefss::map()` API, we can insert a `!Send` or `!Sync` object into `ARefss<'a, V>`. After that, it is possible to create a data race to the inner object of `ARefss<'a, V>`, which can lead to undefined behavior & memory corruption.

The flaw was corrected in commit 6dd7ca0 (https://github.com/diwic/reffers-rs/commit/6dd7ca0d50f2464df708975cdafcfaeeb6d41c66) by adding trait bound `V: Send + Sync` to `ARefss::map()` API.


Summary: difference is unmaintained

The author of the `difference` crate is unresponsive.

Maintained alternatives:

- [`dissimilar`](https://crates.io/crates/dissimilar)

- [`similar`](https://crates.io/crates/similar)

- [`treediff`](https://crates.io/crates/treediff)

- [`diffus`](https://crates.io/crates/diffus)


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


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


Summary: 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
`UsbContext`s across threads.

This issue allows non-thread safe `UsbContext` types to be used concurrently
leading to data races and memory corruption.

The issue was fixed by adding `Send` and `Sync` bounds to `UsbContext`.


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

`aovec::Aovec<T>` 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.


Summary: Double free when calling `sys_info::disk_info` from multiple threads

Affected versions of `sys-info` use a static, global, list to store temporary disk information while running. The function that cleans up this list,
`DFCleanup`, assumes a single threaded environment and will try to free the same memory twice in a multithreaded environment.

This results in consistent double-frees and segfaults when calling `sys_info::disk_info` from multiple threads at once.

The issue was fixed by moving the global variable into a local scope.

## Safer Alternatives:
 - [`sysinfo`](https://crates.io/crates/sysinfo)


Summary: 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 `Send`able 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 adding a `Send` constraint to `OnceCell`.


Summary: 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<T>`).

This can result in a memory corruption or other kinds of undefined behavior.

The flaw was corrected in commit 11f396c by replacing the `T: Send` bound to `T: Sync` bound in the `Sync` impl for `LateStatic<T>`.


Summary: `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 `MaybeUninit<T>` to avoid possible dropping of uninitialized memory upon panic.


Summary: ImageChunkMut needs bounds on its Send and Sync traits

In the affected versions of this crate, `ImageChunkMut<'_, T>` 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 commit e7fb2f5 by adding `T: Send` bound to the `Send` impl and adding `T: Sync` bound to the `Sync` impl.


Summary: Update unsound DrainFilter and RString::retain

Affected versions of this crate contained code from the Rust standard library that contained soundness bugs rust-lang/rust#60977 (double drop) & rust-lang/rust#78498 (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.


Summary: 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<RW, T>`, `InnerRecv<RW, T>`, `FutInnerSend<RW, T>`, `FutInnerRecv<RW, T>`).

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 corrected in v0.1.7 by adding `T: Send` bound to to the `Send` impl of four data types explained above.


Summary: 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 `Send`able types and `Sync`able types.

This allows non-`Sync` types such as `Cell` to be shared across threads leading to undefined behavior and memory corruption in concurrent programs.


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

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


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


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

Affected versions of `may_queue` implements `Send`/`Sync` for its `Queue` type without restricting it to `Send`able types and `Sync`able types.

This allows non-`Sync` types such as `Cell` to be shared across threads leading to undefined behavior and memory corruption in concurrent programs.


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

`ButtplugFutureStateShared<T>` implements `Send` & `Sync` regardless of `T`.

If `T: !Send` for `ButtplugFutureStateShared<T>`, it is possible to move non-Send types across thread boundaries (e.g. `T`=`Rc<T>`) and lead to undefined behavior.
If `T: !Sync` for `ButtplugFutureStateShared<T>`, it is possible to cause data race to `T` (e.g. `T`=`Arc<Cell<_>>`) and lead to undefined behavior.

The flaw was corrected in version 1.0.4 by removing manual implementations of `Send`/`Sync` for `ButtplugFutureStateShared<T>` to let rustc generate auto trait implementations with correct trait bounds on `T`.


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

In the affected versions of this crate,
`AtomicOption<T>` unconditionally implements `Sync`.

This allows programmers to move non-Sync types across thread boundaries (e.g. `Rc<T>`, `Arc<Cell<T>>`), which can lead to data races and undefined behavior.
It is also possible to send non-Send types like `std::sync::MutexGuard` to other threads, which can lead to undefined behavior.


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

In the affected versions of this crate, `Demuxer<T>` 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 data race.

The flaw was corrected in commit 0562cbf by adding a `T: Send` bound to the `Send` impl for `Demuxer<T>`.


Summary: Singleton lacks bounds on Send and Sync.

`Singleton<T>` 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 races in concurrent programs.

The flaw was corrected in commit `b0d2bd20e` by adding trait bounds, requiring
the contaiend type to implement `Sync`.


Summary: 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<T>` & `Unordered<T, S>`. 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 internal mutability without synchronization are contained within `PinSlab<T>` or `Unordered<T, S>` and accessed concurrently from multiple threads.

The flaw was corrected in commits 92f40b4 & 6a6c367 by adding trait bound `T: Send` to `Send` impls for `PinSlab<T>` & `Unordered<T, S>` and adding `T: Sync` to `Sync` impls for `PinSlab<T>` & `Unordered<T, S>`.


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

Affected versions of this crate unconditionally implemented `Send`/`Sync` for `QueueSender<T>`,
allowing to send non-Send `T` to other threads by invoking `(&QueueSender<T>).send()`.

This fails to prevent users from creating data races by sending types like `Rc<T>` or `Arc<Cell<T>>` to other threads, which can lead to memory corruption.

The flaw was corrected in commit 1e462c3 by imposing `T: Send` to both `Send`/`Sync` impls for `QueueSender<T>`/`QueueReceiver<T>`.


Summary: Future<T> lacks bounds on Send and Sync.

`tiny_future` contains a light-weight implementation of `Future`s. 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
`Future`s and cause data races in concurrent programs.

The flaw was corrected in commit `c791919` by adding trait bounds to `Future`'s
`Send` and `Sync`.


Summary: ReadTicket and WriteTicket should only be sendable when T is Send

Affected versions of this crate unconditionally implemented `Send` for `ReadTicket<T>` & `WriteTicket<T>`.
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<T>`/`WriteTicket<T>`). Such data races can cause memory corruption or other undefined behavior.

The flaw was corrected in commit a986a93 by adding `T: Send` bounds to `Send` impls of `ReadTicket<T>`/`WriteTicket<T>`.


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

Affected versions of this crate implements `Send` for `Decoder<R>` for any `R: Read`. This allows `Decoder<R>` 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 the mutex.

The flaw was corrected in commit a34d6e1 by adding trait bound `R: Send` to the `Send` impl for `Decoder<R>`.


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

Affected versions of this crate implements `Send`/`Sync` for `AtomicBox<T>` 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 behavior using safe Rust (e.g. memory corruption from data race).

The flaw was corrected in commit 34c2b9e by adding trait bound `T: Send` to `Send` impl for `AtomicBox<T>` and trait bound `T: Sync` to `Sync` impl for `AtomicBox<T>`.


Summary: 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<'_, T, U>`. 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 trait bounds `T: Sync` and `T::Owned: Send` to the `Send` impl for `Cow<'_, T, U>`.


Summary: Contents of uninitialized memory exposed in DeflateOutput's AsyncRead implementation

Affected versions of this crate passes an uninitialized buffer to a user-provided trait function `AsyncRead::poll_read()`.

Arbitrary `AsyncRead::poll_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 produces undefined values that can quickly invoke undefined behavior.

The flaw was fixed in commit 5ba266a by ensuring the newly allocated part of the buffer is zero-initialized before passing it to a user-provided `AsyncRead::poll_read()`.


Summary: ArcGuard's Send and Sync should have bounds on RC

Affected versions of this crate implement Send/Sync for `ArcGuard<RC, T>` 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 behavior caused by sending `T: !Send` to other threads (e.g. dropping `MutexGuard<T>` in another thread that didn't lock its mutex).


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

Affected versions of this crate unconditionally implement Send/Sync for `ConVec<T>`.
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<Cell<_>>` or `Rc<_>` as `T` in `ConVec<T>`. It is also possible to create data races by using types like `Cell<_>` or `RefCell<_>` as `T` (types that are `Send` but not `Sync`).
Such data races can lead to memory corruption.


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

Affected versions of this crate unconditionally implement Send/Sync for `SyncChannel<T>`.
`SyncChannel<T>` 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. Using `T = Arc<Cell<_>` allows to create data races (which can lead to memory corruption), and using `T = MutexGuard<T>` allows to unlock a mutex from a thread that didn't lock the mutex.


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

Affected versions of this crate unconditionally implement `Sync` for `SyncRef<T>`.
This definition allows data races if `&T` is accessible through `&SyncRef`.

`SyncRef<T>` derives `Clone` and `Debug`, and the default implementations of those traits access `&T` by invoking `T::clone()` & `T::fmt()`. It is possible to create data races & undefined behavior by concurrently invoking `SyncRef<T>::clone()` or `SyncRef<T>::fmt()` from multiple threads with `T: !Sync`.


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

Affected versions of this crate unconditionally implement Send/Sync for `Cache<K>`.
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<Cell<T>>` or `Rc<T>` as `K` in `Cache<K>`. It is also possible to create data races by using types like `Cell<T>` or `RefCell<T>` (types that are `Send` but not `Sync`).
Such data races can lead to memory corruption.


Summary: ShmWriter allows sending non-Send type across threads

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


Summary: Bunch<T> unconditionally implements Send/Sync

Affected versions of this crate unconditionally implements `Send`/`Sync` for `Bunch<T>`.
This allows users to insert `T: !Sync` to `Bunch<T>`. 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 threads by inserting `T` inside `Bunch<T>` and sending `Bunch<T>` to another thread, allowing to create a data race by inserting types like `T = Rc<_>`.

Such data races can lead to memory corruption.


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

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

This can result in memory corruption caused by data races.


Summary: `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<T, A>::clone()`. This causes memory corruption.


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

Affected versions of this crate unconditionally implements `Send`/`Sync` for `Queue<T>`.

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.


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

In the affected versions of this crate, `LockWeak<T>` unconditionally implemented `Send` with no trait bounds on `T`. `LockWeak<T>` 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.


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

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


Summary: CopyCell lacks bounds on its Send trait allowing for data races

`CopyCell<T>` is a `Cell`-like type that is implemented for any type `T` that
is `Copy`able. It's `Send` trait has no bounds on the contained type.

As not all `Copy`able types are thread safe, for example non-mutable references
implement the `Copy` trait, it is possible to send references to types with
interior mutability such as `Cell` across threads and cause data races.


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

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