TQRG/raw-osv-data huggingface dataset:
Vulnerability: RUSTSEC-2019-0012
Summary: Memory corruption in SmallVec::grow()
Aliases: CVE-2019-15554
Published: 2019-07-19T12:00:00Z

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.
Vulnerability: RUSTSEC-2020-0080
Summary: `miow` invalidly assumes the memory layout of std::net::SocketAddr
Aliases: CVE-2020-35921
Published: 2020-11-13T12:00:00Z

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.
Vulnerability: GHSA-gx5w-rrhp-f436
Summary: XSS in mdBook
Aliases: CVE-2020-26297
Severity: HIGH
CWE: CWE-79
Published: 2021-08-25T20:56:20Z

> This is a cross-post of [the official security advisory][ml]. The official post contains a signed version with our PGP key, as well.

[ml]: https://groups.google.com/g/rustlang-security-announcements/c/3-sO6of29O0

The Rust Security Response Working Group was recently notified of a security issue affecting the search feature of mdBook, which could allow an attacker to execute arbitrary JavaScript code on the page.

The CVE for this vulnerability is [CVE-2020-26297](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26297).

## Overview

The search feature of mdBook (introduced in version 0.1.4) was affected by a cross site scripting vulnerability that allowed an attacker to execute arbitrary JavaScript code on an user's browser by tricking the user into typing a malicious search query, or tricking the user into clicking a link to the search page with the malicious search query prefilled.

mdBook 0.4.5 fixes the vulnerability by properly escaping the search query.

## Mitigations

Owners of websites built with mdBook have to upgrade to mdBook 0.4.5 or greater and rebuild their website contents with it. It's possible to install mdBook 0.4.5 on the local system with:

```
cargo install mdbook --version 0.4.5 --force
```

## Acknowledgements

Thanks to Kamil Vavra for responsibly disclosing the vulnerability to us according to [our security policy](https://www.rust-lang.org/policies/security).

## Timeline of events

All times are listed in UTC.

- 2020-12-30 20:14 - The issue is reported to the Rust Security Response WG
- 2020-12-30 20:32 - The issue is acknowledged and the investigation began
- 2020-12-30 21:21 - Found the cause of the vulnerability and prepared the patch
- 2021-01-04 15:00 - Patched version released and vulnerability disclosed
Vulnerability: RUSTSEC-2021-0032
Summary: Deserializing an array can drop uninitialized memory on panic
Aliases: CVE-2021-28033
Published: 2021-03-01T12:00:00Z

The `read_bytes_default_le` function for `[T; n]` arrays, used to deserialize
arrays of `T` from bytes created a `[T; n]` array with `std::mem::uninitialized`
and then called `T`'s deserialization method.

If `T`'s deserialization method panicked, the uninitialized memory could drop
invalid objects.

This flaw was corrected in `a535678` by removing the unsafe block and using
a `.map` function to deserialize each element of the array instead.
Vulnerability: GHSA-c9h5-hf8r-m97x
Summary: Dangling reference in flatbuffers
Aliases: CVE-2020-35864
Severity: HIGH
CWE: CWE-704
Published: 2021-08-25T20:47:36Z

An issue was discovered in the flatbuffers crate through 2020-04-11 for Rust. read_scalar (and read_scalar_at) can transmute values without unsafe blocks.
Vulnerability: RUSTSEC-2020-0079
Summary: `socket2` invalidly assumes the memory layout of std::net::SocketAddr
Aliases: CVE-2020-35920
Published: 2020-11-06T12:00:00Z

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.
Vulnerability: RUSTSEC-2019-0004
Summary: Failure to properly verify ed25519 signatures makes any signature valid
Aliases: CVE-2019-15545
Published: 2019-05-15T12:00:00Z

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.
Vulnerability: GHSA-ppj3-7jw3-8vc4
Summary: Data races in lock_api
Aliases: CVE-2020-35910
Severity: MODERATE
CWE: CWE-362
Published: 2021-08-25T20:49:35Z

An issue was discovered in the lock_api crate before 0.4.2 for Rust. A data race can occur because of MappedMutexGuard unsoundness.
Vulnerability: RUSTSEC-2020-0096
Summary: TreeFocus lacks bounds on its Send and Sync traits
Aliases: CVE-2020-36204
Published: 2020-11-09T12:00:00Z

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.
Vulnerability: GHSA-fqq2-xp7m-xvm8
Summary: Data race in ruspiro-singleton
Aliases: CVE-2020-36435
Severity: HIGH
CWE: CWE-119, CWE-362
Published: 2021-08-25T20:58:19Z

`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`.
Vulnerability: RUSTSEC-2021-0120
Summary: abomonation transmutes &T to and from &[u8] without sufficient constraints
Published: 2021-10-17T12:00:00Z

This transmute is at the core of the abomonation crates. It's so easy to use it to violate alignment requirements that no test in the crate's test suite passes under miri.
The use of this transmute in serialization/deserialization also incorrectly assumes that the layout of a repr(Rust) type is stable.
This transmute can also disclose both the contents of padding bytes which may be an information leak and the contents of pointers, which may be used to defeat ASLR.
Vulnerability: RUSTSEC-2021-0065
Summary: anymap is unmaintained.
Aliases: CVE-2021-38187
Published: 2021-05-07T12:00:00Z

The `anymap` crate does not appear to be maintained, and the most recent
published version 0.12.1 includes a soundness bug. This has been
[fixed](https://github.com/chris-morgan/anymap/pull/32) a few years ago, but
was never released.
Vulnerability: RUSTSEC-2018-0018
Summary: smallvec creates uninitialized value of any type
Published: 2018-09-25T12:00:00Z

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.
Vulnerability: RUSTSEC-2021-0081
Summary: Potential request smuggling capabilities due to lack of input validation
Aliases: CVE-2021-38512
Published: 2021-06-16T12:00:00Z

Affected versions of this crate did not properly detect invalid requests that could allow HTTP/1 request smuggling (HRS) attacks when running alongside a vulnerable front-end proxy server. This can result in leaked internal and/or user data, including credentials, when the front-end proxy is also vulnerable.

Popular front-end proxies and load balancers already mitigate HRS attacks so it is recommended that they are also kept up to date; check your specific set up. You should upgrade even if the front-end proxy receives exclusively HTTP/2 traffic and connects to the back-end using HTTP/1; several downgrade attacks are known that can also expose HRS vulnerabilities.
Vulnerability: GHSA-2r6q-6c8c-g762
Summary: Data races in toolshed
Aliases: CVE-2020-36456
Severity: HIGH
CWE: CWE-77, CWE-362
Published: 2021-08-25T20:58:03Z

An issue was discovered in the toolshed crate through 2020-11-15 for Rust. In CopyCell<T>, the Send trait lacks bounds on the contained type.
Vulnerability: RUSTSEC-2018-0013
Summary: Vec-to-vec transmutations could lead to heap overflow/corruption
Aliases: CVE-2018-21000
Published: 2018-11-27T12:00:00Z

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.
Vulnerability: GHSA-83r8-p8v6-6gfm
Summary: Slock<T> allows sending non-Send types across thread boundaries
Severity: MODERATE
CWE: CWE-362
Published: 2021-08-25T21:00:20Z

`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.
Vulnerability: RUSTSEC-2020-0025
Summary: bigint is unmaintained, use uint instead
Aliases: CVE-2020-35880
Published: 2020-05-07T12:00:00Z

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.
Vulnerability: RUSTSEC-2020-0160
Summary: Threshold value is ignored (all shares are n=3)
Published: 2020-01-21T12:00:00Z

Affected versions of this crate did not properly calculate secret shares requirements.

This reduces the security of the algorithm by restricting the crate to always
using a threshold value of three, rather than a configurable limit.

The flaw was corrected by correctly configuring the threshold.
Vulnerability: RUSTSEC-2017-0001
Summary: scalarmult() vulnerable to degenerate public keys
Aliases: CVE-2017-1000168
Published: 2017-01-26T12:00:00Z

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.
Vulnerability: RUSTSEC-2021-0039
Summary: panic in user-provided `Endian` impl triggers double drop of T
Aliases: CVE-2021-29929
Published: 2021-01-04T12:00:00Z

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

Double-drop (or double free) can cause memory corruption in the heap.
Vulnerability: RUSTSEC-2020-0072
Summary: GenericMutexGuard allows data races of non-Sync types across threads
Aliases: CVE-2020-35915
Published: 2020-10-31T12:00:00Z

`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`.
Vulnerability: GHSA-hhw2-pqhf-vmx2
Summary: Use after free in actix-utils
Aliases: CVE-2020-35898
Severity: CRITICAL
CWE: CWE-416
Published: 2021-08-25T20:49:09Z

An issue was discovered in the actix-utils crate before 2.0.0 for Rust. The Cell implementation allows obtaining more than one mutable reference to the same data.
Vulnerability: RUSTSEC-2020-0137
Summary: AtomicBox<T> lacks bound on its Send and Sync traits allowing data races
Aliases: CVE-2020-36457
Published: 2020-11-10T12:00:00Z

`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.
Vulnerability: GHSA-f9xr-3m55-5q2v
Summary: Data races in cgc
Aliases: CVE-2020-36466
Severity: MODERATE
CWE: CWE-362
Published: 2021-08-25T20:56:14Z

An issue was discovered in the cgc crate through 2020-12-10 for Rust. Ptr implements Send and Sync for all types.
Vulnerability: GHSA-24g6-5rx7-58wj
Summary: Missing Initialization of Resource in pnet
Aliases: CVE-2019-25054
Severity: HIGH
CWE: CWE-909
Published: 2022-01-06T22:18:07Z

An issue was discovered in the pnet crate before 0.27.2 for Rust. There is a segmentation fault (upon attempted dereference of an uninitialized descriptor) because of an erroneous IcmpTransportChannelIterator compiler optimization.
Vulnerability: RUSTSEC-2020-0064
Summary: crate has been renamed to `sn_ffi_utils`
Published: 2020-11-02T12:00:00Z

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

The new repository location is:

<https://github.com/maidsafe/sn_ffi_utils>
Vulnerability: RUSTSEC-2019-0019
Summary: HMAC-BLAKE2 algorithms compute incorrect results
Aliases: CVE-2019-16143
Published: 2019-08-25T12:00:00Z

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.
Vulnerability: RUSTSEC-2020-0121
Summary: AtomicBox<T> implements Send/Sync for any `T: Sized`
Aliases: CVE-2020-36441
Published: 2020-11-10T12:00:00Z

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>`.
Vulnerability: RUSTSEC-2021-0097
Summary: SM2 Decryption Buffer Overflow
Aliases: CVE-2021-3711
Published: 2021-08-24T12:00:00Z

In order to decrypt SM2 encrypted data an application is expected to call the
API function `EVP_PKEY_decrypt()`. Typically an application will call this
function twice. The first time, on entry, the "out" parameter can be NULL and,
on exit, the "outlen" parameter is populated with the buffer size required to
hold the decrypted plaintext. The application can then allocate a sufficiently
sized buffer and call `EVP_PKEY_decrypt()` again, but this time passing a non-NULL
value for the "out" parameter.

A bug in the implementation of the SM2 decryption code means that the
calculation of the buffer size required to hold the plaintext returned by the
first call to `EVP_PKEY_decrypt()` can be smaller than the actual size required by
the second call. This can lead to a buffer overflow when `EVP_PKEY_decrypt()` is
called by the application a second time with a buffer that is too small.

A malicious attacker who is able present SM2 content for decryption to an
application could cause attacker chosen data to overflow the buffer by up to a
maximum of 62 bytes altering the contents of other data held after the
buffer, possibly changing application behaviour or causing the application to
crash. The location of the buffer is application dependent but is typically
heap allocated.
Vulnerability: RUSTSEC-2021-0078
Summary: Lenient `hyper` header parsing of `Content-Length` could allow request smuggling
Aliases: CVE-2021-32715, GHSA-f3pg-qwvg-p99c
Published: 2021-07-07T12:00:00Z

`hyper`'s HTTP header parser accepted, according to RFC 7230, illegal contents inside `Content-Length` headers.
Due to this, upstream HTTP proxies that ignore the header may still forward them along if it chooses to ignore the error.

To be vulnerable, `hyper` must be used as an HTTP/1 server and using an HTTP proxy upstream that ignores the header's contents
but still forwards it. Due to all the factors that must line up, an attack exploiting this vulnerability is unlikely.
Vulnerability: RUSTSEC-2018-0005
Summary: Uncontrolled recursion leads to abort in deserialization
Published: 2018-09-17T12:00:00Z

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.
Vulnerability: GHSA-g87r-23vw-7f87
Summary: Use After Free in rusqlite
Aliases: CVE-2021-45719
Severity: HIGH
CWE: CWE-416
Published: 2022-01-06T22:00:21Z

An issue was discovered in the rusqlite crate 0.25.x before 0.25.4 and 0.26.x before 0.26.2 for Rust. update_hook has a use-after-free.
Vulnerability: GHSA-f3pg-qwvg-p99c
Summary: Lenient Parsing of Content-Length Header When Prefixed with Plus Sign
Aliases: CVE-2021-32715
Severity: LOW
CWE: CWE-444
Published: 2021-07-12T16:54:20Z

### Summary

hyper's HTTP/1 server code had a flaw that incorrectly parses and accepts requests with a `Content-Length` header with a prefixed plus sign, when it should have been rejected as illegal. This combined with an upstream HTTP proxy that doesn't parse such `Content-Length` headers, but forwards them, can result in "request smuggling" or "desync attacks".

### Vulnerability

The flaw exists in all prior versions of hyper, if built with [`rustc` v1.5.0 or newer](https://github.com/rust-lang/rust/pull/28826/commits/123a83326fb95366e94a3be1a74775df4db97739).

Example:

```
GET / HTTP/1.1
Host: example.com
Content-Length: +3

abc
```

This request gets accepted and hyper reads the body as abc. The request _should_ be rejected, according to RFC 7230, since the ABNF for `Content-Length` only allows for `DIGIT`s. This is due to using the `FromStr` implementation for `u64` in the standard library. By differing from the spec, it is possible to send requests like these to endpoints that have different HTTP implementations, with different interpretations of the payload semantics, and cause "desync attacks".

In this particular case, an upstream proxy would need to error when parsing the `Content-Length`, but _not_ reject the request (swallowing its own error), and forwarding the request as-is with the `Content-Length` still included. _Then_ the upstream proxy and hyper would disagree on the length of the request body. The combination of these factors would be extremely rare.

Read more about desync attacks: https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn

### Impact

To determine if vulnerable, all these things must be true:

- **Using hyper as an HTTP server**. While the lenient decoder also exists in the client, a vulnerability does not exist around _responses_.
- **Using HTTP/1**. The HTTP/2 code uses a stricter parser.
- **Using a vulnerable HTTP proxy upstream to hyper**. If an upstream proxy correctly rejects the illegal `Content-Length` header, *OR* can parse the length with the plus sign, the desync attack cannot succeed.

### Patches

We have released the following patch versions:

- v0.14.10 (to be released when this advisor is published)

### Workarounds

Besides upgrading hyper, you can take the following options:

- Reject requests manually that contain a plus sign prefix in the `Content-Length` header.
- Ensure any upstream proxy handles `Content-Length` headers with a plus sign prefix.

### Credits
This issue was initially reported by [Mattias Grenfeldt](https://grenfeldt.dev/) and Asta Olofsson.
Vulnerability: RUSTSEC-2020-0033
Summary: Matrix::new() drops uninitialized memory
Aliases: CVE-2020-36432
Published: 2020-08-25T12:00:00Z

`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.
Vulnerability: GHSA-m833-jv95-mfjh
Summary: Memory safety violation in crayon
Aliases: CVE-2020-35889
Severity: HIGH
CWE: CWE-367
Published: 2021-08-25T20:48:50Z

An issue was discovered in the crayon crate through 2020-08-31 for Rust. A TOCTOU issue has a resultant memory safety violation via HandleLike.
Vulnerability: GHSA-rmff-f8w9-c9rm
Summary: Data races in max7301
Aliases: CVE-2020-36472
Severity: MODERATE
CWE: CWE-362
Published: 2021-08-25T20:59:22Z

The `ImmediateIO` and `TransactionalIO` types implement `Sync` for all contained
`Expander<EI>` types regardless of if the `Expander` itself is safe to use
across threads.

As the `IO` types allow retrieving the `Expander`, this can lead to non-thread
safe types being sent across threads as part of the `Expander` leading to data
races.
Vulnerability: GHSA-xrg3-hmf3-rvgw
Summary: Path Traversal in rust-embed
Aliases: CVE-2021-45712
Severity: HIGH
CWE: CWE-22
Published: 2022-01-06T22:03:56Z

An issue was discovered in the rust-embed crate before 6.3.0 for Rust. A ../ directory traversal can sometimes occur in debug mode.
Vulnerability: RUSTSEC-2021-0003
Summary: Buffer overflow in SmallVec::insert_many
Aliases: CVE-2021-25900
Published: 2021-01-08T12:00:00Z

A bug in the `SmallVec::insert_many` method caused it to allocate a buffer that was smaller than needed.  It then wrote past the end of the buffer, causing a buffer overflow and memory corruption on the heap.

This bug was only triggered if the iterator passed to `insert_many` yielded more items than the lower bound returned from its `size_hint` method.
 
The flaw was corrected in smallvec 0.6.14 and 1.6.1, by ensuring that additional space is always reserved for each item inserted.  The fix also simplified the implementation of `insert_many` to use less unsafe code, so it is easier to verify its correctness.

Thank you to Yechan Bae (@Qwaz) and the Rust group at Georgia Tech’s SSLab for finding and reporting this bug.
Vulnerability: GHSA-hpcx-3pw8-g3j2
Summary: Free of uninitialized memory in telemetry
Aliases: CVE-2021-29937
Severity: CRITICAL
CWE: CWE-908
Published: 2021-08-25T20:54:22Z

An issue was discovered in the telemetry crate through 0.1.2 for Rust. There is a drop of uninitialized memory if a value.clone() call panics within misc::vec_with_size().
Vulnerability: RUSTSEC-2019-0035
Summary: Unaligned memory access
Aliases: GHSA-mmc9-pwm7-qj5w, CVE-2020-25576
Published: 2019-04-19T12:00:00Z

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.
Vulnerability: RUSTSEC-2020-0048
Summary: Use-after-free in BodyStream due to lack of pinning
Aliases: CVE-2020-35901
Published: 2020-01-24T12:00:00Z

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`.
Vulnerability: GHSA-g4w7-3qr8-5623
Summary: Improper type usage in rusqlite
Aliases: CVE-2020-35872
Severity: CRITICAL
CWE: CWE-351
Published: 2021-08-25T20:47:01Z

An issue was discovered in the rusqlite crate before 0.23.0 for Rust. Memory safety can be violated via the repr(Rust) type.
Vulnerability: GHSA-gf93-h79q-6jjv
Summary: Incorrect implementation of the Streebog hash functions in streebog
Aliases: CVE-2019-25006
Severity: HIGH
CWE: CWE-327
Published: 2021-08-25T20:45:41Z

An issue was discovered in the streebog crate before 0.8.0 for Rust. The Streebog hash function can produce the wrong answer.
Vulnerability: RUSTSEC-2021-0054
Summary: Archives may contain uninitialized memory
Aliases: CVE-2021-31919
Published: 2021-04-28T12:00:00Z

`rkyv` is a serialization framework that writes struct-compatible memory to be stored or
transmitted. During serialization, struct padding bytes and unused enum bytes may not be
initialized. These bytes may be written to disk or sent over unsecured channels.
Vulnerability: RUSTSEC-2022-0001
Summary: lmdb is unmaintained, use lmdb-rkv instead
Published: 2022-01-05T12:00:00Z

The lmdb crate hasn't had any updates since August 2018.

Mozilla's [lmdb-rkv](https://github.com/mozilla/lmdb-rs) fork of the crate has received additional maintenance work beyond that and is the best available replacement.
Vulnerability: RUSTSEC-2021-0111
Summary: Memory Safety Issue when using `patch` or `merge` on `state` and assign the result back to `state`
Published: 2021-09-16T12:00:00Z

Affected versions of this crate maintains references to memory that might have been freed already.
If affects the following two `tremor-script` language constructs:

* A [Merge](https://www.tremor.rs/docs/tremor-script/index#merge) where we assign the result back to the target expression
  and the expression to be merged needs to reference the `event`:

```
let state = merge state of event end;
```

* A [Patch](https://www.tremor.rs/docs/tremor-script/index#patch) where we assign the result back to the target expression
  and the patch operations used need to reference the `event`:

```
let state = patch state of insert event.key => event.value end;
```

For constructs like this (it doesnt matter what is references in the expression to be merged or the patch operations) an optimization
was applied to manipulate the target value in-place, instead of cloning it.

Our `Value` struct which underpins all event data in `tremor-script`, is representing as borrowed strings `beef::Cow<'lifetime, str>` 
that reference the actual `Vec<u8>` the event is based upon. We keep the raw byte-array next to the event structure inside our `Event` struct as a self-referential struct,
so we make sure that the structured `Value` and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patche `event` data or static data.
When `state` was introduced to `tremor-script` a new possibility existed, to keep `Value` data around for longer than the lifetime of an event.
If `event` data is merged or patched into `state` without cloning `state` first, it can still reference keys or values from
the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.


## Workaround

If an upgrade is not possible, a possible workaround is to avoid the optimization
by introducing a temporary variable and not immediately reassigning to `state`:

```
let tmp = merge state of event end;
let state = tmp
```

## Fix

The flaw was corrected in `tremor-script` version 0.11.6 via commit [1a2efcd](https://github.com/tremor-rs/tremor-runtime/commit/1a2efcdbe68e5e7fd0a05836ac32d2cde78a0b2e) by removing the optimization
and always clone the target expression of a [Merge](https://www.tremor.rs/docs/tremor-script/index#merge) or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.
Vulnerability: GHSA-8xw8-mmqv-frqq
Summary: fake-static allows converting any reference into a `'static` reference
Severity: HIGH
CWE: CWE-657
Published: 2021-08-25T20:55:33Z

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
Vulnerability: RUSTSEC-2022-0017
Summary: `array!` macro is unsound when its length is impure constant
Published: 2022-04-27T12:00:00Z

Affected versions of this crate did substitute the array length provided by an user at compile-time multiple times.

When an impure constant expression is passed as an array length (such as a result of an impure procedural macro), this can result in the initialization of an array with uninitialized types, which in turn can allow an attacker to execute arbitrary code.

The flaw was corrected in commit [d5b63f72](https://gitlab.com/KonradBorowski/array-macro/-/commit/d5b63f72090f3809c21ac28f9cfd84f12559bf7d) by making sure that array length is substituted just once.
Vulnerability: RUSTSEC-2021-0042
Summary: insert_many can drop elements twice on panic
Aliases: CVE-2021-29933
Published: 2021-01-26T12:00:00Z

Affected versions of `insert_many` used `ptr::copy` to move over items in a
vector to make space before inserting, duplicating their ownership. It then
iterated over a provided `Iterator` to insert the new items.

If the iterator's `.next()` method panics then the vector would drop the same
elements twice.
Vulnerability: RUSTSEC-2021-0107
Summary: Miner fails to get block template when a cell used as a cell dep has been destroyed.
Aliases: GHSA-v666-6w97-pcwm
Published: 2021-07-25T12:00:00Z

## Impact

The RPC get_block_template fails when a cell has been used as a cell dep and an input in the different transactions.

Say cell C is used as a dep group in the transaction A, and is destroyed in the transaction B.

The node adds transaction A first, then B into the transaction pool. They are both valid. But when generating the block template, if the fee rate of B is higher, it comes before A, which will invalidate A. Currently the RPC get_block_template will fail instead of dropping A.

## Patch

First, the get_block_template should not fail but dropping the conflict transactions.

Then we can propose solution to this issue. Here is an example. When a transaction is added to the pool, the pool must consider it depending on all the transactions which dep cell (direct or indirect via dep group) has been destroyed in this transaction. Because future transactions using the destroyed cells as dep will be rejected, the spending transaction only need to wait for all the existing dep transactions on chain.

## Workaround

    Submit transaction B when A is already on chain.
    Let B depend on A explicitly, there are several solutions:
        a. Add any output cell on A as a dep cell or input in B.
        b. Merge A and B. CKB allows using the same cell as both dep and input in the same transaction.
    Ensure the fee rate of B is less than A so A always has higher priority.
Vulnerability: RUSTSEC-2020-0009
Summary: `read_scalar` and `read_scalar_at` allow transmuting values without `unsafe` blocks
Aliases: CVE-2020-35864
Published: 2020-04-11T12:00:00Z

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>()]));
}
```
Vulnerability: RUSTSEC-2021-0015
Summary: `Sectors::get` accesses unclaimed/uninitialized memory
Aliases: CVE-2021-26951
Published: 2021-01-06T12:00:00Z

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

This can overwrite active entities in adjacent heap memory and seems to be a major security issue. Also, calling user-provided `Read` on uninitialized memory is defined as UB in Rust.
Vulnerability: GHSA-r43h-gmrm-h5c9
Summary: Access of Uninitialized Pointer in linked-hash-map
Aliases: CVE-2020-25573
Severity: CRITICAL
CWE: CWE-824
Published: 2021-08-25T20:45:09Z

An issue was discovered in the linked-hash-map crate before 0.5.3 for Rust. It creates an uninitialized NonNull pointer, which violates a non-null constraint.
Vulnerability: GHSA-cw98-cx2m-9qqg
Summary: Denial of Service in ckb
Aliases: CVE-2021-45700
Severity: HIGH
CWE: CWE-400
Published: 2022-01-06T22:10:08Z

An issue was discovered in the ckb crate before 0.40.0 for Rust. Attackers can cause a denial of service (Nervos CKB blockchain node crash) via a dead call that is used as a DepGroup.
Vulnerability: GHSA-37jj-wp7g-7wj4
Summary: Read of uninitialized memory in cdr
Aliases: CVE-2021-26305
Severity: CRITICAL
CWE: CWE-908
Published: 2021-08-25T20:53:12Z

An issue was discovered in Deserializer::read_vec in the cdr crate before 0.2.4 for Rust. A user-provided Read implementation can gain access to the old contents of newly allocated heap memory, violating soundness.
Vulnerability: RUSTSEC-2019-0023
Summary: Cloned interners may read already dropped strings
Aliases: CVE-2019-16882
Published: 2019-08-24T12:00:00Z

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.
Vulnerability: GHSA-83mx-573x-5rw9
Summary: Null pointer deference in openssl-src
Aliases: CVE-2021-3449
Severity: MODERATE
CWE: CWE-476
Published: 2021-08-25T20:54:02Z

An OpenSSL TLS server may crash if sent a maliciously crafted renegotiation ClientHello message from a client. If a TLSv1.2 renegotiation ClientHello omits the signature_algorithms extension (where it was present in the initial ClientHello), but includes a signature_algorithms_cert extension then a NULL pointer dereference will result, leading to a crash and a denial of service attack. A server is only vulnerable if it has TLSv1.2 and renegotiation enabled (which is the default configuration). OpenSSL TLS clients are not impacted by this issue. All OpenSSL 1.1.1 versions are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1k. OpenSSL 1.0.2 is not impacted by this issue. Fixed in OpenSSL 1.1.1k (Affected 1.1.1-1.1.1j).
Vulnerability: RUSTSEC-2020-0029
Summary: Allows viewing and modifying arbitrary structs as bytes
Aliases: CVE-2020-25016
Published: 2020-06-14T12:00:00Z

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.
Vulnerability: GHSA-6gvc-4jvj-pwq4
Summary: Use after free in libpulse-binding
Aliases: CVE-2018-25001
Severity: MODERATE
CWE: CWE-416
Published: 2021-08-30T16:22:34Z

An issue was discovered in the libpulse-binding crate before 2.5.0 for Rust. proplist::Iterator can cause a use-after-free.
Vulnerability: GHSA-v4cp-h94r-m7xf
Summary: Use after free passing `externref`s to Wasm in Wasmtime
Aliases: CVE-2021-39216
Severity: MODERATE
CWE: CWE-416
Published: 2021-09-20T19:54:05Z

### Impact

There was a use-after-free bug when passing `externref`s from the host to guest Wasm content.

To trigger the bug, you have to explicitly pass multiple `externref`s from the host to a Wasm instance at the same time, either by

* passing multiple `externref`s as arguments from host code to a Wasm function,
* or returning multiple `externref`s to Wasm from a multi-value return function defined in the host.
 
If you do not have host code that matches one of these shapes, then you are not impacted.

If Wasmtime's [`VMExternRefActivationsTable`](https://github.com/bytecodealliance/wasmtime/blob/37c094faf53f1b356aab3c79d451395e4f7edb34/crates/runtime/src/externref.rs#L493) became filled to capacity after passing the first `externref` in, then passing in the second `externref` could trigger a garbage collection. However the first `externref` is not rooted until we pass control to Wasm, and therefore could be reclaimed by the collector if nothing else was holding a reference to it or otherwise keeping it alive. Then, when control was passed to Wasm after the garbage collection, Wasm could use the first `externref`, which at this point has already been freed.

We have reason to believe that the effective impact of this bug is relatively small because usage of `externref` is currently quite rare.

### Patches

The bug has been fixed, and users should upgrade to Wasmtime 0.30.0.

Additionally, we have updated [our primary `externref` fuzz target](https://github.com/bytecodealliance/wasmtime/blob/37c094faf53f1b356aab3c79d451395e4f7edb34/fuzz/fuzz_targets/table_ops.rs) such that it better exercises these code paths and we can have greater confidence in their correctness going forward.

### Workarounds

If you cannot upgrade Wasmtime yet, you can avoid the bug by disabling reference types support in Wasmtime by passing `false` to [`wasmtime::Config::wasm_reference_types`](https://docs.rs/wasmtime/0.29.0/wasmtime/struct.Config.html#method.wasm_reference_types).

### References

* [The reference types Wasm proposal, which introduces `externref`](https://github.com/WebAssembly/reference-types/)

### For more information

If you have any questions or comments about this advisory:

* Reach out to us on [the Bytecode Alliance Zulip chat](https://bytecodealliance.zulipchat.com/#narrow/stream/217126-wasmtime)
* Open an issue in [the `bytecodealliance/wasmtime` repository](https://github.com/bytecodealliance/wasmtime/)
Vulnerability: RUSTSEC-2021-0127
Summary: serde_cbor is unmaintained
Published: 2021-08-15T12:00:00Z

The `serde_cbor` crate is unmaintained. The author has archived the github repository.

Alternatives proposed by the author:

 * [`ciborium`](https://crates.io/crates/ciborium)
 * [`minicbor`](https://crates.io/crates/minicbor)
Vulnerability: GHSA-7cqg-8449-rmfv
Summary: Observable Discrepancy in libsecp256k1-rs
Aliases: CVE-2019-20399
Severity: MODERATE
CWE: CWE-203, CWE-362
Published: 2021-08-25T21:01:27Z

A timing vulnerability in the Scalar::check_overflow function in Parity libsecp256k1-rs before 0.3.1 potentially allows an attacker to leak information via a side-channel attack.
Vulnerability: RUSTSEC-2021-0062
Summary: project abandoned; migrate to the `aes-siv` crate
Published: 2021-02-28T12:00:00Z

The Miscreant project has been abandoned and archived.

The Rust implementation has been adapted into the new `aes-siv` crate which
implements both the AES-CMAC-SIV and AES-PMAC-SIV constructions:

<https://github.com/RustCrypto/AEADs/tree/master/aes-siv>

Please migrate to the `aes-siv` crate.

Alternatively see the `aes-gcm-siv` crate for a newer, faster construction
which provides similar properties:

<https://github.com/RustCrypto/AEADs/tree/master/aes-gcm-siv>
Vulnerability: GHSA-wp34-mqw5-jj85
Summary: Use after free in nano_arena
Aliases: CVE-2021-28032
Severity: CRITICAL
CWE: CWE-416
Published: 2021-08-25T20:52:00Z

An issue was discovered in the nano_arena crate before 0.5.2 for Rust. There is an aliasing violation in split_at because two mutable references can exist for the same element, if Borrow<Idx> behaves in certain ways. This can have a resultant out-of-bounds write or use-after-free.
Vulnerability: RUSTSEC-2019-0003
Summary: Out of Memory in stream::read_raw_bytes_into()
Aliases: CVE-2019-15544
Published: 2019-06-08T12:00:00Z

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.
Vulnerability: RUSTSEC-2020-0091
Summary: Dangling reference in `access::Map` with Constant
Aliases: CVE-2020-35711
Published: 2020-12-10T12:00:00Z

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.
Vulnerability: GHSA-jqpv-jm4m-86j9
Summary: Use After Free in libpulse-binding
Aliases: CVE-2018-25028
Severity: HIGH
CWE: CWE-416
Published: 2022-01-06T22:17:50Z

An issue was discovered in the libpulse-binding crate before 1.2.1 for Rust. get_context can cause a use-after-free.
Vulnerability: GHSA-qpgv-g792-wh6x
Summary: Uncontrolled Resource Consumption in parse_duration
Aliases: CVE-2021-29932
Severity: HIGH
CWE: CWE-400
Published: 2021-08-25T20:54:04Z

An issue was discovered in the parse_duration crate through 2021-03-18 for Rust. It allows attackers to cause a denial of service (CPU and memory consumption) via a duration string with a large exponent.
Vulnerability: GHSA-66p5-j55p-32r9
Summary: smallvec creates uninitialized value of any type
Severity: MODERATE
CWE: CWE-457
Published: 2021-08-25T21:00:25Z

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.
Vulnerability: RUSTSEC-2021-0035
Summary: `quinn` invalidly assumes the memory layout of std::net::SocketAddr
Aliases: CVE-2021-28036
Published: 2021-03-04T12:00:00Z

The [`quinn`](https://crates.io/crates/quinn) 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.
Vulnerability: RUSTSEC-2019-0015
Summary: Flaw in generativity allows out-of-bounds access
Aliases: CVE-2019-16139
Published: 2019-05-21T12:00:00Z

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.
Vulnerability: RUSTSEC-2020-0068
Summary: Unexpected panic in multihash `from_slice` parsing code
Aliases: CVE-2020-35909
Published: 2020-11-08T12:00:00Z

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.
Vulnerability: RUSTSEC-2020-0087
Summary: TryMutex<T> allows sending non-Send type across threads
Aliases: CVE-2020-35924
Published: 2020-11-17T12:00:00Z

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.
Vulnerability: GHSA-4x25-pvhw-5224
Summary: Algorithms compute incorrect results in blake2
Aliases: CVE-2019-16143
Severity: HIGH
CWE: CWE-327
Published: 2021-08-25T20:44:20Z

An issue was discovered in the blake2 crate before 0.8.1 for Rust. The BLAKE2b and BLAKE2s algorithms, when used with HMAC, produce incorrect results because the block sizes are half of the required sizes.
Vulnerability: GHSA-wxjf-9f4g-3v44
Summary: Data races in noise_search
Aliases: CVE-2020-36461
Severity: MODERATE
CWE: CWE-77, CWE-362
Published: 2021-08-25T20:56:05Z

Affected versions of the `noise_search` crate unconditionally implement Send/Sync for `MvccRwLock`.
This can lead to data races when types that are either `!Send` or `!Sync` (e.g. `Rc<T>`, `Arc<Cell<_>>`) are contained inside `MvccRwLock` and sent across thread boundaries. The data races can potentially lead to memory corruption (as demonstrated in the PoC from the original report issue).

Also, safe APIs of `MvccRwLock` allow aliasing violations by allowing `&T` and `LockResult<MutexGuard<Box<T>>>` to co-exist in conflicting lifetime regions. The APIs of `MvccRwLock` should either be marked as `unsafe` or `MbccRwLock` should be changed to private or pub(crate).
Vulnerability: GHSA-r57r-j98g-587f
Summary: Pointer dereference in nanorand
Aliases: CVE-2021-45705
Severity: CRITICAL
Published: 2022-01-06T22:08:56Z

An issue was discovered in the nanorand crate before 0.6.1 for Rust. There can be multiple mutable references to the same object because the TlsWyRand Deref implementation dereferences a raw pointer.
Vulnerability: RUSTSEC-2021-0023
Summary: Incorrect check on buffer length when seeding RNGs
Aliases: CVE-2021-27378
Published: 2021-02-12T12:00:00Z

Summary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled.

Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.
Vulnerability: GHSA-j35p-q24r-5367
Summary: Dep Group Remote Memory Exhaustion (Denial of Service) in ckb
Severity: HIGH
Published: 2022-04-22T20:23:04Z

### Impact
A remote attacker could exploit this vulnerability to exhaust ckb process memory of an affected node.

### Patches
Upgrade to 0.43.1 or later.

### References
After resolving the outpoints of one dep group, we put the corresponding content into a vec ( https://github.com/nervosnetwork/ckb/blob/v0.42.0/util/types/src/core/cell.rs#L600-L617 ), there is a vulnerability to a memory dos attack because there is no determination of whether the outpoints is duplicated.

PoC:
```
before send dos tx rss:
105700

after rss:
2306932
```

DoS cost: 25.6 KB * 150 + dep_tx out_points capacity ( 36 * 150 * 100 = 540000 ) = 4380000 CKB
Send 50 dos_tx, memory exhausted: (25.6 KB * 150  * 100) * 50 = 19.2 GB