TQRG/raw-osv-data huggingface dataset:
Vulnerability: RUSTSEC-2020-0040
Summary: Obstack generates unaligned references
Aliases: CVE-2020-35894
Published: 2020-09-03T12:00:00Z

Obstack generates unaligned references for types that require a large alignment.
Vulnerability: RUSTSEC-2020-0105
Summary: Update unsound DrainFilter and RString::retain
Aliases: CVE-2020-36213, CVE-2020-36212
Published: 2020-12-21T12:00:00Z

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.
Vulnerability: GHSA-2v78-j59h-fmpf
Summary: Heap overflow or corruption in safe-transmute
Aliases: CVE-2018-21000
Severity: CRITICAL
CWE: CWE-119
Published: 2021-08-25T20:43:23Z

An issue was discovered in the safe-transmute crate before 0.10.1 for Rust. A constructor's arguments are in the wrong order, causing heap memory corruption.
Vulnerability: RUSTSEC-2021-0070
Summary: VecStorage Deserialize Allows Violation of Length Invariant
Aliases: CVE-2021-38190
Published: 2021-06-06T12:00:00Z

The `Deserialize` implementation for `VecStorage` did not maintain the invariant that the number of elements must equal `nrows * ncols`. Deserialization of specially crafted inputs could allow memory access beyond allocation of the vector.

This flaw was introduced in v0.11.0 ([`086e6e`](https://github.com/dimforge/nalgebra/commit/086e6e719f53fecba6dadad2e953a487976387f5)) due to the addition of an automatically derived implementation of `Deserialize` for `MatrixVec`. `MatrixVec` was later renamed to `VecStorage` in v0.16.13 ([`0f66403`](https://github.com/dimforge/nalgebra/commit/0f66403cbbe9eeac15cedd8a906c0d6a3d8841f2)) and continued to use the automatically derived implementation of `Deserialize`.

This flaw was corrected in commit [`5bff536`](https://github.com/dimforge/nalgebra/commit/5bff5368bf38ddfa31416e4ae9897b163031a513) by returning an error during deserialization if the number of elements does not exactly match the expected size.
Vulnerability: RUSTSEC-2021-0135
Summary: Improper validation of Windows paths could lead to directory traversal attack
Published: 2021-01-21T12:00:00Z

`tower_http::services::fs::ServeDir` didn't correctly validate Windows paths
meaning paths like `/foo/bar/c:/windows/web/screen/img101.png` would be allowed
and respond with the contents of `c:/windows/web/screen/img101.png`. Thus users
could potentially read files anywhere on the filesystem.

This only impacts Windows. Linux and other unix likes are not impacted by this.

See [tower-http#204] for more details.

[tower-http#204]: https://github.com/tower-rs/tower-http/pull/204
Vulnerability: GHSA-wcvp-r8j8-47pc
Summary: Double free in toodee
Aliases: CVE-2021-28028
Severity: CRITICAL
CWE: CWE-415
Published: 2021-09-01T18:30:35Z

An issue was discovered in the toodee crate before 0.3.0 for Rust. Row insertion can cause a double free upon an iterator panic.
Vulnerability: GHSA-rccq-j2m7-8fwr
Summary: Double-free in id-map
Aliases: CVE-2021-30457
Severity: CRITICAL
CWE: CWE-415
Published: 2021-08-25T20:55:14Z

An issue was discovered in the id-map crate through 2021-02-26 for Rust. A double free can occur in remove_set upon a panic in a Drop impl.
Vulnerability: RUSTSEC-2021-0027
Summary: Loading a bgzip block can write out of bounds if size overflows.
Aliases: CVE-2021-28027
Published: 2021-01-07T12:00:00Z

Affected versions of `bam` set the length of an internal buffer using
`self.compressed.set_len(block_size - HEADER_SIZE - MIN_EXTRA_SIZE)` and then
wrote into it. While `block_size` was constrained to a proper maximum, when it
was too small the subtraction could overflow negatively to a large number past
the capacity of `self.compressed`.

This can result in memory corruption in the form of writing out of bounds when
loading a `bgzip` file with a small `block_size`.

Commit `061eee38d4` fixed this issue by checking for the underflow when setting
the buffer size.
Vulnerability: RUSTSEC-2016-0003
Summary: HTTP download and execution allows MitM RCE
Aliases: CVE-2016-10933
Published: 2016-08-01T12:00:00Z

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.
Vulnerability: RUSTSEC-2020-0083
Summary: crate has been superseded by `sn_client`
Published: 2020-12-07T12:00:00Z

This crate has been superseded by `sn_client`.

The new repository location is:

<https://github.com/maidsafe/sn_client>
Vulnerability: RUSTSEC-2020-0129
Summary: ShmWriter allows sending non-Send type across threads
Aliases: CVE-2020-36449
Published: 2020-12-18T12:00:00Z

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.
Vulnerability: RUSTSEC-2019-0011
Summary: Flaw in offset_of and span_of causes SIGILL, drops uninitialized memory of arbitrary type on panic in client code
Aliases: CVE-2019-15553
Published: 2019-07-16T12:00:00Z

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`.
Vulnerability: RUSTSEC-2021-0031
Summary: split_at allows obtaining multiple mutable references to the same data
Aliases: CVE-2021-28032
Published: 2021-01-31T12:00:00Z

Affected versions of this crate assumed that `Borrow<Idx>` was guaranteed to
return the same value on `.borrow()`. The borrowed index value was used to
retrieve a mutable reference to a value.

If the `Borrow<Idx>` implementation returned a different index, the split arena
would allow retrieving the index as a mutable reference creating two mutable
references to the same element. This violates Rust's aliasing rules and allows
for memory safety issues such as writing out of bounds and use-after-frees.

The flaw was corrected in commit `6b83f9d` by storing the `.borrow()` value in
a temporary variable.
Vulnerability: RUSTSEC-2020-0095
Summary: difference is unmaintained
Published: 2020-12-20T12:00:00Z

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)
Vulnerability: RUSTSEC-2019-0007
Summary: Processing of maliciously crafted length fields causes memory allocation SIGABRTs
Aliases: CVE-2019-15549
Published: 2019-06-13T12:00:00Z

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.
Vulnerability: RUSTSEC-2021-0066
Summary: Denial of service on EVM execution due to memory over-allocation
Published: 2021-05-11T12:00:00Z

Prior to the patch, when executing specific EVM opcodes related
to memory operations that use `evm_core::Memory::copy_large`, the
crate can over-allocate memory when it is not needed, making it
possible for an attacker to perform denial-of-service attack.

The flaw was corrected in commit `19ade85`.
Vulnerability: GHSA-862g-9h5m-m3qv
Summary: coreos-installer < 0.10.0 writes world-readable Ignition config to installed system
Aliases: CVE-2021-3917
Severity: LOW
Published: 2021-11-08T18:01:13Z

### Impact
On systems installed with coreos-installer before 0.10.0, the user-provided Ignition config was written to `/boot/ignition/config.ign` with world-readable permissions, granting unprivileged users access to any secrets included in the config.

Default configurations of Fedora CoreOS and RHEL CoreOS do not include any unprivileged user accounts.  In addition, instances launched from a cloud image, and systems provisioned with the `ignition.config.url` kernel argument, do not use the `config.ign` file and are unaffected.

### Patches
coreos-installer 0.10.0 and later [writes](https://github.com/coreos/coreos-installer/pull/571) the Ignition config with restricted permissions.

### Workarounds

On Fedora CoreOS systems installed from version 34.20210711.3.0 (stable), 34.20210711.2.0 (testing), 34.20210711.1.1 (next) and later, the `/boot/ignition` directory and its contents are removed after provisioning is complete. All Fedora CoreOS systems that have updated to these versions or later have automatically removed the `/boot/ignition` directory and no action is required.

On other systems, `/boot/ignition/config.ign` can be removed manually, as it is not used after provisioning is complete:

```
sudo mount -o remount,rw /boot
sudo rm -rf /boot/ignition
```

### References
For more information, see https://github.com/coreos/fedora-coreos-tracker/issues/889.

### For more information
If you have any questions or comments about this advisory, [open an issue in coreos-installer](https://github.com/coreos/coreos-installer/issues/new/choose) or email the CoreOS [development mailing list](https://lists.fedoraproject.org/archives/list/coreos@lists.fedoraproject.org/).
Vulnerability: GHSA-x3mh-jvjw-3xwx
Summary: Infinite loop in `BN_mod_sqrt()` reachable when parsing certificates
Aliases: CVE-2022-0778
Severity: HIGH
CWE: CWE-835
Published: 2022-03-16T00:00:45Z

The BN_mod_sqrt() function, which computes a modular square root, contains a bug that can cause it to loop forever for non-prime moduli. Internally this function is used when parsing certificates that contain elliptic curve public keys in compressed form or explicit elliptic curve parameters with a base point encoded in compressed form. It is possible to trigger the infinite loop by crafting a certificate that has invalid explicit curve parameters. Since certificate parsing happens prior to verification of the certificate signature, any process that parses an externally supplied certificate may thus be subject to a denial of service attack. The infinite loop can also be reached when parsing crafted private keys as they can contain explicit elliptic curve parameters. Thus vulnerable situations include: - TLS clients consuming server certificates - TLS servers consuming client certificates - Hosting providers taking certificates or private keys from customers - Certificate authorities parsing certification requests from subscribers - Anything else which parses ASN.1 elliptic curve parameters Also any other applications that use the BN_mod_sqrt() where the attacker can control the parameter values are vulnerable to this DoS issue. In the OpenSSL 1.0.2 version the public key is not parsed during initial parsing of the certificate which makes it slightly harder to trigger the infinite loop. However any operation which requires the public key from the certificate will trigger the infinite loop. In particular the attacker can use a self-signed certificate to trigger the loop during verification of the certificate signature. This issue affects OpenSSL versions 1.0.2, 1.1.1 and 3.0. It was addressed in the releases of 1.1.1n and 3.0.2 on the 15th March 2022. Fixed in OpenSSL 3.0.2 (Affected 3.0.0,3.0.1). Fixed in OpenSSL 1.1.1n (Affected 1.1.1-1.1.1m). Fixed in OpenSSL 1.0.2zd (Affected 1.0.2-1.0.2zc).
Vulnerability: RUSTSEC-2021-0123
Summary: Converting `NSString` to a String Truncates at Null Bytes
Aliases: CVE-2021-43620
Published: 2021-11-14T12:00:00Z

Methods of [`NSString`] for conversion to a string may return a partial result.
Since they call [`CStr::from_ptr`] on a pointer to the string buffer, the
string is terminated at the first null byte, which might not be the end of the
string.

In addition to the vulnerable functions listed for this issue, the
implementations of [`Display`], [`PartialEq`], [`PartialOrd`], and [`ToString`]
for [`NSString`] are also affected, since they call those functions.

## Impact

Since [`NSString`] is commonly used as the type for paths by the [Foundation]
framework, null byte truncation might allow for easily bypassing file extension
checks. For example, if a file name is provided by a user and validated to have
one of a specific set of extensions, with validation taking place before
truncation, an attacker can add an accepted extension after a null byte (e.g.,
`file.exe\0.txt`). After truncation, the file name used by the application
would be `file.exe`.

It would be better to generate unique names for files, instead of using
user-provided names, but not all applications take this approach.

## Example:

```rust
let string = NSString::from_str("null\0byte");
println!("{}", string);
```

That example only prints the string "null".

[`CStr::from_ptr`]: https://doc.rust-lang.org/std/ffi/struct.CStr.html#method.from_ptr
[`Display`]: https://doc.rust-lang.org/std/fmt/trait.Display.html
[Foundation]: https://developer.apple.com/documentation/foundation
[`NSString`]: https://docs.rs/fruity/0.2.0/fruity/foundation/struct.NSString.html
[`PartialEq`]: https://doc.rust-lang.org/std/cmp/trait.PartialEq.html
[`PartialOrd`]: https://doc.rust-lang.org/std/cmp/trait.PartialOrd.html
[`ToString`]: https://doc.rust-lang.org/std/string/trait.ToString.html
Vulnerability: RUSTSEC-2021-0089
Summary: Optional `Deserialize` implementations lacking validation
Published: 2021-01-20T12:00:00Z

When activating the non-default feature `serialize`, most structs implement
`serde::Deserialize` without sufficient validation. This allows breaking
invariants in safe code, leading to:

* Undefined behavior in `as_string()` methods (which use
  `std::str::from_utf8_unchecked()` internally).
* Panics due to failed assertions.

See https://github.com/gz/rust-cpuid/issues/43.
Vulnerability: GHSA-cv7x-6rc6-pq5v
Summary: Double free in containers
Aliases: CVE-2021-25907
Severity: CRITICAL
CWE: CWE-415
Published: 2021-08-25T20:53:05Z

An issue was discovered in the containers crate before 0.9.11 for Rust. When a panic occurs, a util::{mutate,mutate2} double drop can be performed.
Vulnerability: GHSA-mp6f-p9gp-vpj9
Summary: Array size is not checked in sized-chunks
Aliases: CVE-2020-25792
Severity: HIGH
CWE: CWE-129
Published: 2021-08-25T20:46:06Z

An issue was discovered in the sized-chunks crate through 0.6.2 for Rust. In the Chunk implementation, the array size is not checked when constructed with pair().
Vulnerability: RUSTSEC-2019-0027
Summary: Flaw in Scalar::check_overflow allows side-channel timing attack
Aliases: CVE-2019-25003
Published: 2019-10-14T12:00:00Z

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.
Vulnerability: GHSA-55m5-whcv-c49c
Summary: Use of Uninitialized Resource in smallvec
Aliases: CVE-2018-25023
Severity: HIGH
CWE: CWE-908
Published: 2022-01-06T22:20:28Z

An issue was discovered in the smallvec crate before 0.6.13 for Rust. It can create an uninitialized value of any type, including a reference type.
Vulnerability: GHSA-rg4m-gww5-7p47
Summary: Free of uninitialized memory in adtensor
Aliases: CVE-2021-29936
Severity: CRITICAL
CWE: CWE-908
Published: 2021-08-25T20:54:18Z

An issue was discovered in the adtensor crate through 0.0.3 for Rust. There is a drop of uninitialized memory via the FromIterator implementation for Vector and Matrix.
Vulnerability: RUSTSEC-2021-0011
Summary: EventList's From<EventList> conversions can double drop on panic.
Aliases: CVE-2021-25908
Published: 2021-01-04T12:00:00Z

Affected versions of this crate read from a container using `ptr::read` in
`From<EventList>`, and then call a user specified `Into<Event>` function.

This issue can result in a double-free if the user provided function panics.
Vulnerability: GHSA-w7j2-35mf-95p7
Summary: Incorrect check on buffer length in rand_core
Aliases: CVE-2021-27378
Severity: CRITICAL
CWE: CWE-330
Published: 2021-08-25T20:52:16Z

An issue was discovered in the rand_core crate before 0.6.2 for Rust. Because `read_u32_into` and `read_u64_into` mishandle certain buffer-length checks, a random number generator may be seeded with too little data. The vulnerability was introduced in v0.6.0. The advisory doesn't apply to earlier minor version numbers.
Vulnerability: RUSTSEC-2020-0148
Summary: Multiple soundness issues in `Ptr`
Aliases: CVE-2020-36466, CVE-2020-36467, CVE-2020-36468
Published: 2020-12-10T12:00:00Z

Affected versions of this crate have the following issues:

1. `Ptr` implements `Send` and `Sync` for all types, this can lead to data
   races by sending non-thread safe types across threads.

2. `Ptr::get` violates mutable alias rules by returning multiple mutable
   references to the same object.

3. `Ptr::write` uses non-atomic writes to the underlying pointer. This means
   that when used across threads it can lead to data races.
Vulnerability: RUSTSEC-2021-0103
Summary:  Partial read is incorrect in molecule
Aliases: GHSA-82hm-vh7g-hrh9
Published: 2021-07-30T12:00:00Z

Anyone who uses total_size(..) function to partial read the length of any FixVec will get an incorrect result, due to an incorrect implementation. This has been resolved in the 0.7.2 release.
Vulnerability: GHSA-7j44-fv4x-79g9
Summary: Improper Input Validation in once_cell
Aliases: CVE-2019-16141
Severity: MODERATE
CWE: CWE-20
Published: 2021-08-25T20:44:18Z

An issue was discovered in the once_cell crate before 1.0.1 for Rust. There is a panic during initialization of Lazy.
Vulnerability: RUSTSEC-2021-0046
Summary: misc::vec_with_size() can drop uninitialized memory if clone panics
Aliases: CVE-2021-29937
Published: 2021-02-17T12:00:00Z

`misc::vec_with_size` creates a vector of the provided `size` and immediately
calls `vec.set_len(size)` on it, initially filling it with uninitialized memory.
It then inserts elements using `vec[i] = value.clone()`.

If the `value.clone()` call panics, uninitialized items in the vector will be
dropped leading to undefined behavior.
Vulnerability: RUSTSEC-2022-0013
Summary: Regexes with large repetitions on empty sub-expressions take a very long time to parse
Aliases: CVE-2022-24713
Published: 2022-03-08T12:00:00Z

The Rust Security Response WG was notified that the `regex` crate did not
properly limit the complexity of the regular expressions (regex) it parses. An
attacker could use this security issue to perform a denial of service, by
sending a specially crafted regex to a service accepting untrusted regexes. No
known vulnerability is present when parsing untrusted input with trusted
regexes.

This issue has been assigned CVE-2022-24713. The severity of this vulnerability
is "high" when the `regex` crate is used to parse untrusted regexes. Other uses
of the `regex` crate are not affected by this vulnerability.

## Overview

The `regex` crate features built-in mitigations to prevent denial of service
attacks caused by untrusted regexes, or untrusted input matched by trusted
regexes. Those (tunable) mitigations already provide sane defaults to prevent
attacks. This guarantee is documented and it's considered part of the crate's
API.

Unfortunately a bug was discovered in the mitigations designed to prevent
untrusted regexes to take an arbitrary amount of time during parsing, and it's
possible to craft regexes that bypass such mitigations. This makes it possible
to perform denial of service attacks by sending specially crafted regexes to
services accepting user-controlled, untrusted regexes.

## Affected versions

All versions of the `regex` crate before or equal to 1.5.4 are affected by this
issue. The fix is include starting from  `regex` 1.5.5.

## Mitigations

We recommend everyone accepting user-controlled regexes to upgrade immediately
to the latest version of the `regex` crate.

Unfortunately there is no fixed set of problematic regexes, as there are
practically infinite regexes that could be crafted to exploit this
vulnerability. Because of this, we do not recommend denying known problematic
regexes.

## Acknowledgements

We want to thank Addison Crump for responsibly disclosing this to us according
to the [Rust security policy][1], and for helping review the fix.

We also want to thank Andrew Gallant for developing the fix, and Pietro Albini
for coordinating the disclosure and writing this advisory.

[1]: https://www.rust-lang.org/policies/security
Vulnerability: GHSA-w47j-hqpf-qw9w
Summary: Out of bounds read in lazy-init
Aliases: CVE-2021-25901
Severity: MODERATE
CWE: CWE-125
Published: 2021-08-25T20:52:59Z

An issue was discovered in the lazy-init crate through 2021-01-17 for Rust. Lazy lacks a Send bound, leading to a data race.
Vulnerability: GHSA-p9gf-gmfv-398m
Summary: Double free in slice_deque
Aliases: CVE-2021-29938
Severity: HIGH
CWE: CWE-415
Published: 2021-08-25T20:54:16Z

An issue was discovered in the slice-deque crate through 2021-02-19 for Rust. A double drop can occur in SliceDeque::drain_filter upon a panic in a predicate function.
Vulnerability: GHSA-vpw8-43wm-rxw5
Summary: Double free in endian_trait
Aliases: CVE-2021-29929
Severity: HIGH
CWE: CWE-415
Published: 2021-08-25T20:54:06Z

An issue was discovered in the endian_trait crate through 2021-01-04 for Rust. A double drop can occur when a user-provided Endian impl panics.
Vulnerability: RUSTSEC-2021-0115
Summary: `#[zeroize(drop)]` doesn't implement `Drop` for `enum`s
Published: 2021-09-24T12:00:00Z

Affected versions of this crate did not implement `Drop` when `#[zeroize(drop)]` was used on an `enum`.

This can result in memory not being zeroed out after dropping it, which is exactly what is intended when adding this attribute.

The flaw was corrected in version 1.2 and `#[zeroize(drop)]` on `enum`s now properly implements `Drop`.
Vulnerability: GHSA-v5m7-53cv-f3hx
Summary: Undefined Behavior crossbeam-channel
Aliases: CVE-2020-15254
Severity: HIGH
CWE: CWE-119
Published: 2021-08-25T21:01:13Z

### Impact

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.

### Patches

This has been fixed in crossbeam-channel 0.4.4.

We recommend users to upgrade to 0.4.4.

### References

See https://github.com/crossbeam-rs/crossbeam/pull/533, https://github.com/crossbeam-rs/crossbeam/issues/539, and https://github.com/RustSec/advisory-db/pull/425 for more details.
Vulnerability: GHSA-j52m-489x-v634
Summary: Double free in linea
Aliases: CVE-2019-16880
Severity: CRITICAL
CWE: CWE-415
Published: 2021-08-25T20:44:13Z

An issue was discovered in the linea crate through 0.9.4 for Rust. There is double free in the Matrix::zip_elements method.
Vulnerability: GHSA-vjrq-cg9x-rfjp
Summary: Improper Input Validation in cookie
Aliases: CVE-2017-18589
Severity: HIGH
CWE: CWE-20
Published: 2021-08-25T20:43:02Z

An issue was discovered in the cookie crate before 0.7.6 for Rust. Large integers in the Max-Age of a cookie cause a panic.
Vulnerability: GHSA-49fq-pw77-6qxj
Summary: Use after free in string-interner
Aliases: CVE-2019-16882
Severity: HIGH
CWE: CWE-416
Published: 2021-08-25T20:44:15Z

An issue was discovered in the string-interner crate before 0.7.1 for Rust. It allows attackers to read from memory locations associated with dangling pointers, because of a cloning flaw.
Vulnerability: RUSTSEC-2022-0005
Summary: crate has been renamed to `ftdi-embedded-hal`
Published: 2022-01-22T12:00:00Z

This crate has been renamed from `ftd2xx-embedded-hal` to `ftdi-embedded-hal`.

The new repository location is:

<https://github.com/ftdi-rs/ftdi-embedded-hal>
Vulnerability: RUSTSEC-2021-0050
Summary: swap_index can write out of bounds and return uninitialized memory
Aliases: CVE-2021-29941, CVE-2021-29942
Published: 2021-02-24T12:00:00Z

`swap_index` takes an iterator and swaps the items with their corresponding
indexes. It reserves capacity and sets the length of the vector based on the
`.len()` method of the iterator.

If the `len()` returned by the iterator is larger than the actual number of
elements yielded, then `swap_index` creates a vector containing uninitialized
members. If the `len()` returned by the iterator is smaller than the actual
number of members yielded, then `swap_index` can write out of bounds past
its allocated vector.

As noted by the Rust documentation, [`len()`](https://doc.rust-lang.org/std/iter/trait.ExactSizeIterator.html#method.len)
and `size_hint()` are primarily meant for optimization and incorrect values
from their implementations should not lead to memory safety violations.


# Patch

A new version crate was pushed that marks this function as unsafe.

reorder = "1.1.0"

Previous versions have also been yanked from crates.io.
Vulnerability: RUSTSEC-2020-0109
Summary: stderr is unmaintained; use eprintln instead
Published: 2020-12-22T12:00:00Z

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.
Vulnerability: GHSA-3933-wvjf-pcvc
Summary: Out of bounds access in lucet-runtime-internals
Aliases: CVE-2020-35859
Severity: CRITICAL
CWE: CWE-125, CWE-787
Published: 2021-08-25T20:46:16Z

An issue was discovered in the lucet-runtime-internals crate before 0.5.1 for Rust. It mishandles sigstack allocation. Guest programs may be able to obtain sensitive information, or guest programs can experience memory corruption.
Vulnerability: GHSA-mmc9-pwm7-qj5w
Summary: Unaligned memory access in rand_core
Aliases: CVE-2020-25576
Severity: CRITICAL
CWE: CWE-704
Published: 2021-08-25T20:56:50Z

### Impact
Affected versions of this crate violated alignment when casting byte slices to integer slices, resulting in undefined behavior. `rand_core::BlockRng::next_u64` and `rand_core::BlockRng::fill_bytes` are affected.

### Patches
The flaw was corrected by Ralf Jung and Diggory Hardy for `rand_core >= 0.4.2`.

### Workarounds
None.

### References
See [Rand's changelog](https://github.com/rust-random/rand/blob/master/rand_core/CHANGELOG.md#050---2019-06-06).

### For more information
If you have any questions or comments about this advisory, [open an issue in the Rand repository](https://github.com/rust-random/rand/issues/new/choose).
Vulnerability: GHSA-7j36-gc4r-9x3r
Summary: Out of bounds access in compact_arena
Aliases: CVE-2019-16139
Severity: CRITICAL
CWE: CWE-125, CWE-787
Published: 2021-08-25T20:44:48Z

An issue was discovered in the compact_arena crate before 0.4.0 for Rust. Generativity is mishandled, leading to an out-of-bounds write or read.
Vulnerability: GHSA-686h-j8r8-wmfm
Summary: Data races in rcu_cell
Aliases: CVE-2020-36451
Severity: HIGH
CWE: CWE-77, CWE-362
Published: 2021-08-25T20:57:14Z

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.
Vulnerability: RUSTSEC-2021-0007
Summary: `Frame::copy_from_raw_parts` can lead to segfault without `unsafe`
Aliases: CVE-2021-25904
Published: 2021-01-07T12:00:00Z

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

The flaw was corrected in https://github.com/rust-av/rust-av/pull/137,
by removing the API `fn Frame::copy_from_raw_parts()`.
Vulnerability: RUSTSEC-2020-0037
Summary: Misbehaving `HandleLike` implementation can lead to memory safety violation
Aliases: CVE-2020-35889
Published: 2020-08-31T12:00:00Z

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.
Vulnerability: GHSA-64j8-7gp2-xjx5
Summary: Data races in try-mutex
Aliases: CVE-2020-35924
Severity: MODERATE
CWE: CWE-787
Published: 2021-08-25T20:50:28Z

An issue was discovered in the try-mutex crate before 0.3.0 for Rust. TryMutex<T> allows cross-thread sending of a non-Send type.
Vulnerability: GHSA-vh4p-6j7g-f4j9
Summary: Data races in lock_api
Aliases: CVE-2020-35911
Severity: MODERATE
CWE: CWE-362
Published: 2021-08-25T20:49:56Z

An issue was discovered in the lock_api crate before 0.4.2 for Rust. A data race can occur because of MappedRwLockReadGuard unsoundness.
Vulnerability: RUSTSEC-2018-0001
Summary: An integer underflow could lead to panic
Aliases: CVE-2018-20989
Published: 2018-06-21T12:00:00Z

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.
Vulnerability: RUSTSEC-2021-0093
Summary: Data race in crossbeam-deque
Aliases: GHSA-pqqp-xmhj-wgcw, CVE-2021-32810
Published: 2021-07-30T12:00:00Z

In the affected version of this crate, the result of the race condition is that one or more tasks in the worker queue can be popped twice instead of other tasks that are forgotten and never popped. If tasks are allocated on the heap, this can cause double free and a memory leak. If not, this still can cause a logical bug.

Crates using `Stealer::steal`, `Stealer::steal_batch`, or `Stealer::steal_batch_and_pop` are affected by this issue.

Credits to @kmaork for discovering, reporting and fixing the bug.
Vulnerability: RUSTSEC-2020-0125
Summary: convec::ConVec<T> unconditionally implements Send/Sync
Aliases: CVE-2020-36445
Published: 2020-11-24T12:00:00Z

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.
Vulnerability: GHSA-fhvj-7f9p-w788
Summary: Buffer overflow in arr
Aliases: CVE-2020-35887
Severity: CRITICAL
CWE: CWE-120
Published: 2021-08-25T20:48:54Z

An issue was discovered in the arr crate through 2020-08-25 for Rust. There is a buffer overflow in Index and IndexMut.
Vulnerability: RUSTSEC-2020-0060
Summary: futures_task::waker may cause a use-after-free if used on a type that isn't 'static
Aliases: CVE-2020-35906
Published: 2020-09-04T12:00:00Z

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.
Vulnerability: GHSA-qc84-gqf4-9926
Summary: Improper Restriction of Operations within the Bounds of a Memory Buffer and Race Condition in crossbeam-utils
Aliases: CVE-2022-23639
Severity: CRITICAL
CWE: CWE-119, CWE-362
Published: 2022-02-16T22:36:21Z

### Impact

The affected version of this crate incorrectly assumed that the alignment of `{i,u}64` was always the same as `Atomic{I,U}64`. 

However, the alignment of `{i,u}64` on a 32-bit target can be smaller than `Atomic{I,U}64`.

This can cause the following problems:

- Unaligned memory accesses
- Data race

Crates using `fetch_*` methods with `AtomicCell<{i,u}64>` are affected by this issue.

32-bit targets without `Atomic{I,U}64` and 64-bit targets are not affected by this issue.
32-bit targets with `Atomic{I,U}64` and `{i,u}64` have the same alignment are also not affected by this issue.

The following is a complete list of the builtin targets that may be affected. (last update: nightly-2022-02-11)

- armv7-apple-ios (tier 3)
- armv7s-apple-ios (tier 3)
- i386-apple-ios (tier 3)
- i586-unknown-linux-gnu
- i586-unknown-linux-musl
- i686-apple-darwin (tier 3)
- i686-linux-android
- i686-unknown-freebsd
- i686-unknown-haiku (tier 3)
- i686-unknown-linux-gnu
- i686-unknown-linux-musl
- i686-unknown-netbsd (tier 3)
- i686-unknown-openbsd (tier 3)
- i686-wrs-vxworks (tier 3)

([script to get list](https://gist.github.com/taiki-e/3c7891e8c5f5e0cbcb44d7396aabfe10))

### Patches

This has been fixed in crossbeam-utils 0.8.7.

Affected 0.8.x releases have been yanked.

### References

https://github.com/crossbeam-rs/crossbeam/pull/781
Vulnerability: GHSA-c5hx-w945-j4pq
Summary: Memory flaw in zeroize_derive
Aliases: CVE-2021-45706
Severity: CRITICAL
Published: 2022-01-06T22:08:33Z

An issue was discovered in the zeroize_derive crate before 1.1.1 for Rust. Dropped memory is not zeroed out for an enum.
Vulnerability: GHSA-2jfv-g3fh-xq3v
Summary: Excessive memory usage in tokio-rustls
Aliases: CVE-2020-35875
Severity: HIGH
CWE: CWE-400
Published: 2021-08-25T20:46:54Z

An issue was discovered in the tokio-rustls crate before 0.13.1 for Rust. Excessive memory usage may occur when data arrives quickly.
Vulnerability: GHSA-h5wh-7h2j-h999
Summary: Exposure of Resource to Wrong Sphere in Simple-Wayland-HotKey-Daemon
Aliases: CVE-2022-27817
Severity: MODERATE
CWE: CWE-668
Published: 2022-04-15T00:00:40Z

SWHKD 1.1.5 consumes the keyboard events of unintended users. This could potentially cause an information leak, but is usually a denial of functionality.
Vulnerability: RUSTSEC-2020-0099
Summary: Aovec<T> lacks bound on its Send and Sync traits allowing data races
Aliases: CVE-2020-36207
Published: 2020-12-10T12:00:00Z

`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.
Vulnerability: RUSTSEC-2020-0133
Summary: Queue<T> should have a Send bound on its Send/Sync traits
Aliases: CVE-2020-36453
Published: 2020-11-15T12:00:00Z

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.
Vulnerability: GHSA-v2ch-fc8f-qm33
Summary: Use of Uninitialized Resource in bite.
Aliases: CVE-2020-36511
Severity: HIGH
CWE: CWE-908
Published: 2022-01-06T22:16:57Z

An issue was discovered in the bite crate through 2020-12-31 for Rust. read::BiteReadExpandedExt::read_framed_max may read from uninitialized memory locations.
Vulnerability: GHSA-2xpg-3hx4-fm9r
Summary: Out of bounds read in xcb
Aliases: CVE-2021-26957
Severity: CRITICAL
CWE: CWE-125
Published: 2021-08-25T20:53:20Z

An issue was discovered in the xcb crate through 2021-02-04 for Rust. It has a soundness violation because there is an out-of-bounds read in xcb::xproto::change_property(), as demonstrated by a format=32 T=u8 situation where out-of-bounds bytes are sent to an X server.
Vulnerability: RUSTSEC-2020-0076
Summary: crate has been renamed to `sn_routing`
Published: 2020-11-02T12:00:00Z

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

The new repository location is:

<https://github.com/maidsafe/sn_routing>
Vulnerability: RUSTSEC-2017-0005
Summary: Large cookie Max-Age values can cause a denial of service
Aliases: CVE-2017-18589
Published: 2017-05-06T12:00:00Z

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.
Vulnerability: RUSTSEC-2020-0021
Summary: rio allows a use-after-free buffer access when a future is leaked
Aliases: CVE-2020-35876
Published: 2020-05-11T12:00:00Z

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.
Vulnerability: RUSTSEC-2018-0017
Summary: `tempdir` crate has been deprecated; use `tempfile` instead
Published: 2018-02-13T12:00:00Z

The [`tempdir`](https://crates.io/crates/tempdir) crate has been deprecated
and the functionality is merged into [`tempfile`](https://crates.io/crates/tempfile).
Vulnerability: RUSTSEC-2021-0085
Summary: 'Read' on uninitialized memory may cause UB
Published: 2021-01-03T12:00:00Z

Affected versions of this crate passes an uninitialized buffer to a user-provided `Read` implementation. The crate currently contains 4 occurrences of such cases.

Arbitrary `Read` implementations can read from the uninitialized buffer (memory exposure) and also can return incorrect number of bytes written to the buffer.
Reading from uninitialized memory produces undefined values that can quickly invoke undefined behavior.
Vulnerability: GHSA-p4jg-pccf-h82c
Summary: Insecure Temporary File in SWHKD
Aliases: CVE-2022-27815
Severity: CRITICAL
CWE: CWE-377
Published: 2022-03-31T00:00:24Z

SWHKD is a display protocol-independent hotkey daemon made in Rust. In SWHKD versions 1.1.5 and prior, SWHKD uses the /tmp/swhkd.pid pathname. As /tmp is accessible to all users, there can be an information leak or denial of service. No known workarounds exist. A patch is available on the `1.1.0` branch of the repository.
Vulnerability: GHSA-g4xg-fxmg-vcg5
Summary: OS command injection in ripgrep
Aliases: CVE-2021-3013
Severity: CRITICAL
CWE: CWE-78
Published: 2021-08-05T19:31:55Z

ripgrep before 13 on Windows allows attackers to trigger execution of arbitrary programs from the current working directory via the -z/--search-zip or --pre flag.
Vulnerability: GHSA-96w3-p368-4h8c
Summary: Use after free in internment
Aliases: CVE-2020-35874
Severity: HIGH
CWE: CWE-362
Published: 2021-08-25T20:46:51Z

An issue was discovered in the internment crate through 2020-05-28 for Rust. ArcIntern::drop has a race condition and resultant use-after-free.
Vulnerability: RUSTSEC-2018-0016
Summary: quickersort is deprecated and unmaintained
Published: 2018-06-30T12:00:00Z

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
Vulnerability: RUSTSEC-2021-0084
Summary: `Read` on uninitialized buffer can cause UB (impl of `ReadKVExt`)
Published: 2021-01-03T12:00:00Z

Affected versions of this crate passes an uninitialized buffer to a user-provided `Read` implementation.

Arbitrary `Read` implementations can read from the uninitialized buffer (memory exposure) and also can return incorrect number of bytes written to the buffer.
Reading from uninitialized memory produces undefined values that can quickly invoke undefined behavior.
Vulnerability: GHSA-36xw-hgfv-jwm7
Summary: Uninitialized memory drop in arr
Aliases: CVE-2020-35888
Severity: CRITICAL
CWE: CWE-908
Published: 2021-08-25T20:48:36Z

An issue was discovered in the arr crate through 2020-08-25 for Rust. Uninitialized memory is dropped by Array::new_from_template.
Vulnerability: GHSA-v666-6w97-pcwm
Summary: Miner fails to get block template when a cell used as a cell dep has been destroyed.
Severity: HIGH
CWE: CWE-367
Published: 2021-08-25T21:01:21Z

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

1. Submit transaction B when A is already on chain.
2. 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.
3. Ensure the fee rate of B is less than A so A always has higher priority.
Vulnerability: RUSTSEC-2017-0004
Summary: Integer overflow leads to heap-based buffer overflow in encode_config_buf
Aliases: CVE-2017-1000430
Published: 2017-05-03T12:00:00Z

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.
Vulnerability: RUSTSEC-2020-0020
Summary: `stb_truetype` crate has been deprecated; use `ttf-parser` instead
Published: 2020-04-18T12:00:00Z

This crate was maintained for use in rusttype which has switched to use [ttf-parser](https://crates.io/crates/ttf-parser)
Vulnerability: GHSA-qrwc-jxf5-g8x6
Summary: Out of bounds read in ordnung
Aliases: CVE-2020-35890
Severity: HIGH
CWE: CWE-125
Published: 2021-08-25T20:48:40Z

An issue was discovered in the ordnung crate through 2020-09-03 for Rust. compact::Vec violates memory safety via out-of-bounds access for large capacity.
Vulnerability: GHSA-6q5w-m3c5-rv95
Summary: Data races in rusqlite
Aliases: CVE-2020-35866
Severity: CRITICAL
CWE: CWE-362
Published: 2021-08-25T20:47:59Z

An issue was discovered in the rusqlite crate before 0.23.0 for Rust. Memory safety can be violated via VTab / VTabCursor.
Vulnerability: RUSTSEC-2020-0098
Summary: UsbContext trait did not require implementers to be Send and Sync.
Aliases: CVE-2020-36206
Published: 2020-12-18T12:00:00Z

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`.
Vulnerability: RUSTSEC-2020-0132
Summary: `FixedCapacityDequeLike::clone()` can cause dropping uninitialized memory
Aliases: CVE-2020-36452
Published: 2020-12-31T12:00:00Z

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.
Vulnerability: RUSTSEC-2020-0077
Summary: memmap is unmaintained
Published: 2020-12-02T12:00:00Z

The author of the `memmap` crate is unresponsive.

Maintained alternatives:

- [`mapr`](https://github.com/filecoin-project/mapr)
- [`memmap2`](https://github.com/RazrFalcon/memmap2-rs)
Vulnerability: GHSA-g489-xrw3-3v8w
Summary: Data races in aovec
Aliases: CVE-2020-36207
Severity: HIGH
CWE: CWE-662, CWE-787
Published: 2021-08-25T20:50:46Z

An issue was discovered in the aovec crate through 2020-12-10 for Rust. Because Aovec<T> does not have bounds on its Send trait or Sync trait, a data race and memory corruption can occur.
Vulnerability: GHSA-mc36-5m36-hjh5
Summary: Data races in slock
Aliases: CVE-2020-36455
Severity: HIGH
CWE: CWE-77, CWE-362
Published: 2021-08-25T20:58:00Z

An issue was discovered in the slock crate through 2020-11-17 for Rust. Slock<T> unconditionally implements Send and Sync.
Vulnerability: RUSTSEC-2020-0124
Summary: ArcGuard's Send and Sync should have bounds on RC
Aliases: CVE-2020-36444
Published: 2020-12-08T12:00:00Z

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).
Vulnerability: GHSA-3227-r97m-8j95
Summary: Relative Path Traversal in afire serve_static
Severity: HIGH
CWE: CWE-34, CWE-22
Published: 2022-04-22T20:16:45Z

### Impact
This vulnerability effects the built-in afire serve_static extension allowing paths containing `//....` to bypass the previous path sanitation and request files in higher directories that should not be accessible.

### Patches
The issue has been fixed in [afire 1.1.0](https://crates.io/crates/afire/1.1.0).
If you can, just update to the newest version of afire.

### Workarounds
If you can't update afire you can simply disallow paths containing `/..` with the following middleware.
Make sure this is the last middleware added to the server so it runs first, stopping the bad requests.
```rust
use afire::prelude::*;

struct PathTraversalFix;

impl Middleware for PathTraversalFix {
    fn pre(&self, req: Request) -> MiddleRequest {
        if req.path.replace("\\", "/").contains("/..") {
            return MiddleRequest::Send(
                Response::new()
                    .status(400)
                    .text("Paths containing `..` are not allowed"),
            );
        }

        MiddleRequest::Continue
    }
}
```
```rust
let mut server = Server::new(host, port);
PathTraversalFix.attach(&mut server);
```

### References
You can read about the new changes to afire in 1.1.0 [here](https://connorcode.com/writing/afire/update-3)

### For more information
If you have any questions or comments about this advisory you can email me or message me on discord.
[[https://connorcode.com/contact](https://connorcode.com/contact)]