TQRG/raw-osv-data huggingface dataset:
Vulnerability: RUSTSEC-2021-0131
Summary: Integer overflow in the bundled Brotli C library
Aliases: CVE-2020-8927
Published: 2021-12-20T12:00:00Z

A buffer overflow exists in the Brotli library versions prior to 1.0.8 where an attacker controlling the input length of a "one-shot" decompression request to a script can trigger a crash, which happens when copying over chunks of data larger than 2 GiB.

An updated version of `brotli-sys` has not been released. If one cannot update the C library, its authors recommend to use the "streaming" API as opposed to the "one-shot" API, and impose chunk size limits.

In Rust the issue can be mitigated by migrating to the `brotli` crate, which provides a Rust implementation of Brotli compression and decompression that is not affected by this issue.
Vulnerability: GHSA-773q-5334-5gf9
Summary: Memory over-allocation in evm-core
Severity: MODERATE
CWE: CWE-789
Published: 2021-08-25T20:55:36Z

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: RUSTSEC-2018-0009
Summary: MsQueue and SegQueue suffer from double-free
Aliases: CVE-2018-20996
Published: 2018-12-09T12:00:00Z

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

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

Thanks to @c0gent for reporting the issue.
Vulnerability: RUSTSEC-2021-0074
Summary: Incorrect handling of embedded SVG and MathML leads to mutation XSS
Aliases: CVE-2021-38193
Published: 2021-07-08T12:00:00Z

Affected versions of this crate did not account for namespace-related parsing
differences between HTML, SVG, and MathML. Even if the `svg` and `math` elements
are not allowed, the underlying HTML parser still treats them differently.
Running cleanup without accounting for these differing namespaces resulted in an "impossible"
DOM, which appeared "safe" when examining the DOM tree, but when serialized and deserialized,
could be exploited to inject abitrary markup.

To exploit this, the application using this library must allow a tag that is parsed as raw text in HTML.
These [elements] are:

* title
* textarea
* xmp
* iframe
* noembed
* noframes
* plaintext
* noscript
* style
* script

Applications that do not explicitly allow any of these tags should not be affected, since none are allowed by default.

[elements]: https://github.com/servo/html5ever/blob/57eb334c0ffccc6f88d563419f0fbeef6ff5741c/html5ever/src/tree_builder/rules.rs
Vulnerability: RUSTSEC-2020-0101
Summary: conquer-once's OnceCell lacks Send bound for its Sync trait.
Aliases: CVE-2020-36208
Published: 2020-12-22T12:00:00Z

Affected versions of `conquer-once` implements `Sync` for its `OnceCell` type
without restricting it to `Send`able types.

This allows non-`Send` but `Sync` types such as `MutexGuard` to be sent across
threads leading to undefined behavior and memory corruption in concurrent
programs.

The issue was fixed by adding a `Send` constraint to `OnceCell`.
Vulnerability: RUSTSEC-2020-0044
Summary: Unsafe Send implementation in Atom allows data races
Aliases: CVE-2020-35897
Published: 2020-09-21T12:00:00Z

The `atom` crate contains a security issue revolving around its implementation
of the Send trait. It incorrectly allows any arbitrary type to be sent across
threads potentially leading to use-after-free issues through memory races.
Vulnerability: GHSA-79wf-qcqv-r22r
Summary: Remote code execution in better-macro
Aliases: CVE-2021-38196
Severity: HIGH
CWE: CWE-94, CWE-78
Published: 2021-08-25T20:56:00Z

An issue was discovered in the better-macro crate through 2021-07-22 for Rust. It intentionally demonstrates that remote attackers can execute arbitrary code via proc-macros, and otherwise has no legitimate purpose.
Vulnerability: GHSA-xr7r-88qv-q7hm
Summary: Out of bounds write in serde_cbor
Aliases: CVE-2019-25001
Severity: HIGH
CWE: CWE-787
Published: 2021-08-25T20:45:51Z

An issue was discovered in the serde_cbor crate before 0.10.2 for Rust. The CBOR deserializer can cause stack consumption via nested semantic tags.
Vulnerability: RUSTSEC-2020-0156
Summary: Observable Discrepancy in libsecp256k1-rs
Aliases: CVE-2019-20399, GHSA-7cqg-8449-rmfv
Published: 2020-01-22T12:00:00Z

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: GHSA-3vjm-36rr-7qrq
Summary: NULL Pointer Dereference in cbox
Aliases: CVE-2020-35860
Severity: CRITICAL
CWE: CWE-476
Published: 2021-08-25T20:47:16Z

An issue was discovered in the cbox crate through 2020-03-19 for Rust. The CBox API allows dereferencing raw pointers without a requirement for unsafe code.
Vulnerability: RUSTSEC-2020-0013
Summary: fake-static allows converting any reference into a `'static` reference
Published: 2020-04-24T12:00:00Z

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

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

https://github.com/rust-lang/rust/issues/25860
Vulnerability: RUSTSEC-2021-0058
Summary: Null pointer deref in `X509_issuer_and_serial_hash()`
Aliases: CVE-2021-23841
Published: 2021-05-01T12:00:00Z

The OpenSSL public API function `X509_issuer_and_serial_hash()` attempts to
create a unique hash value based on the issuer and serial number data contained
within an X509 certificate. However it fails to correctly handle any errors
that may occur while parsing the issuer field (which might occur if the issuer
field is maliciously constructed). This may subsequently result in a NULL
pointer deref and a crash leading to a potential denial of service attack.

The function `X509_issuer_and_serial_hash()` is never directly called by OpenSSL
itself so applications are only vulnerable if they use this function directly
and they use it on certificates that may have been obtained from untrusted
sources.
Vulnerability: GHSA-ghpq-vjxw-ch5w
Summary: Use after free in libpulse-binding
Severity: HIGH
CWE: CWE-416
Published: 2021-08-25T20:56:52Z

### Overview

Version 1.2.1 of the `libpulse-binding` Rust crate, released on the 15th of June 2018, fixed a pair of use-after-free issues with the objects returned by the `get_format_info` and `get_context` methods of `Stream` objects. These objects were mistakenly being constructed without setting an important flag to prevent destruction of the underlying C objects they reference upon their own destruction.

This advisory is being written retrospectively, having previously only been noted in the changelog. No CVE assignment was sought.

### Patches

Users are required to update to version 1.2.1 or newer.

Versions older than 1.2.1 have been yanked from crates.io. This was believed to have already been done at the time of the 1.2.1 release, but upon double checking now they were found to still be available, so has been done now (22nd October 2020).
Vulnerability: GHSA-wrvc-72w7-xpmj
Summary: Incorrect Comparison in sodiumoxide
Aliases: CVE-2019-25002
Severity: CRITICAL
CWE: CWE-697
Published: 2021-08-25T20:45:54Z

An issue was discovered in the sodiumoxide crate before 0.2.5 for Rust. generichash::Digest::eq compares itself to itself and thus has degenerate security properties.
Vulnerability: RUSTSEC-2020-0140
Summary: `Shared` can cause a data race
Aliases: CVE-2020-36460
Published: 2020-11-10T12:00:00Z

`Shared` data structure in `model` crate implements `Send` and `Sync` traits regardless of the inner type.
This allows safe Rust code to trigger a data race, which is undefined behavior in Rust.

Users are advised to treat `Shared` as an unsafe type.
It should not be used outside of the testing context,
and care must be taken so that the testing code does not have a data race
besides a race condition that is expected to be caught by the test.

Check [the Rustonomicon](https://doc.rust-lang.org/nomicon/races.html) for the difference between
a data race and a general race condition.
Vulnerability: RUSTSEC-2020-0005
Summary: CBox API allows to de-reference raw pointers without `unsafe` code
Aliases: CVE-2020-35860
Published: 2020-03-19T12:00:00Z

`CBox` and `CSemiBox` are part of the public API of the cbox crate
and they allow to create smart pointers from raw pointers and de-reference
them without the need of `unsafe` code.
Vulnerability: GHSA-xwxc-j97j-84gf
Summary: Race condition in Parc
Severity: MODERATE
CWE: CWE-362
Published: 2021-08-25T21:00:03Z

In the affected versions of this crate, `LockWeak<T>` unconditionally implemented `Send` with no trait bounds on `T`. `LockWeak<T>` doesn't own `T` and only provides `&T`.

This allows concurrent access to a non-Sync `T`, which can cause undefined behavior like data races.
Vulnerability: RUSTSEC-2020-0117
Summary: QueueSender<T>/QueueReceiver<T>: Send/Sync impls need `T: Send`
Aliases: CVE-2020-36437
Published: 2020-11-24T12:00:00Z

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

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

The flaw was corrected in commit 1e462c3 by imposing `T: Send` to both `Send`/`Sync` impls for `QueueSender<T>`/`QueueReceiver<T>`.
Vulnerability: RUSTSEC-2020-0052
Summary: Undefined Behavior in bounded channel
Aliases: CVE-2020-35904, GHSA-v5m7-53cv-f3hx, CVE-2020-15254
Published: 2020-06-26T12:00:00Z

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.
Vulnerability: RUSTSEC-2021-0019
Summary: Multiple soundness issues
Aliases: CVE-2021-26957, CVE-2021-26958, CVE-2021-26955, CVE-2021-26956
Published: 2021-02-04T12:00:00Z

## Calls `std::str::from_utf8_unchecked()` without any checks

The function `xcb::xproto::GetAtomNameReply::name()` calls
`std::str::from_utf8_unchecked()` on the raw bytes that were received from the
X11 server without any validity checks. The X11 server only prevents interior
null bytes, but otherwise allows any X11 client to create an atom for arbitrary
bytes.

This issue is tracked here: https://github.com/rust-x-bindings/rust-xcb/issues/96

## `xcb::xproto::GetPropertyReply::value()` allows arbitrary return types

The function `xcb::xproto::GetPropertyReply::value()` returns a slice of type
`T` where `T` is an unconstrained type parameter. The raw bytes received from
the X11 server are interpreted as the requested type.

The users of the `xcb` crate are advised to only call this function with the
intended types. These are `u8`, `u16`, and `u32`.

This issue is tracked here: https://github.com/rust-x-bindings/rust-xcb/issues/95

## Out of bounds read in `xcb::xproto::change_property()`

`xcb::xproto::change_property` has (among others) the arguments `format: u8` and
`data: &[T]`. The intended use is one of the following cases:
- `format = 8` and `T = u8`
- `format = 16` and `T = u16`
- `format = 32` and `T = u32`
However, this constraint is not enforced. For example, it is possible to call
the function with `format = 32` and `T = u8`. In this case, a read beyond the
end of the `data` slice is performed and the bytes are sent to the X11 server.

The users of the `xcb` crate are advised to only call this function with one of
the intended argument combinations.

This issue is tracked here: https://github.com/rust-x-bindings/rust-xcb/issues/94

## 'Safe' wrapper around `std::mem::transmute()`

The function `xcb::base::cast_event()` takes a reference to a
`xcb::base::GenericEvent` and returns a reference to an arbitrary type, as
requested by the caller (or found via type interference). The function is
implemented as a direct call to `std::mem::transmute()`. Since the return type
is not constrained, this allows transmution to an incorrect type or a type that
is larger than the X11 event that was passed in.

X11 events are mostly always 32 bytes large and this function works as intended.

Users are advised to only cast to the event structs provided by the `xcb` crate
(and hope for the best).

This issue is tracked here: https://github.com/rust-x-bindings/rust-xcb/issues/78
Vulnerability: GHSA-5pg8-h4gv-m3p8
Summary: Null pointer deference in fltk
Aliases: CVE-2021-28306
Severity: HIGH
CWE: CWE-476
Published: 2021-08-25T20:53:56Z

An issue was discovered in the fltk crate before 0.15.3 for Rust. There is a NULL pointer dereference during attempted use of a multi label type if the image is nonexistent.
Vulnerability: GHSA-fhv4-fx3v-77w6
Summary: quinn invalidly assumes the memory layout of std::net::SocketAddr
Aliases: CVE-2021-28036
Severity: HIGH
CWE: CWE-119
Published: 2021-08-25T20:52:05Z

An issue was discovered in the quinn crate for Rust. It may have invalid memory access for certain versions of the standard library because it relies on a direct cast of std::net::SocketAddrV4 and std::net::SocketAddrV6 data structures.
Vulnerability: RUSTSEC-2021-0018
Summary: insert_slice_clone can double drop if Clone panics.
Aliases: CVE-2021-26954
Published: 2021-02-03T12:00:00Z

Affected versions of this crate used `ptr::copy` when inserting into the middle
of a `Vec`. When ownership was temporarily duplicated during this copy, it calls
the clone method of a user provided element.

This issue can result in an element being double-freed if the clone call panics.

Commit `20cb73d` fixed this issue by adding a `set_len(0)` call before
operating on the vector to avoid dropping the elements during a panic.
Vulnerability: GHSA-75cq-g75g-rxff
Summary: use-after-free vulnerability in Rust array-queue
Aliases: CVE-2020-35900
Severity: MODERATE
CWE: CWE-416
Published: 2021-08-25T21:00:43Z

An issue was discovered in the array-queue crate through 2020-09-26 for Rust. A pop_back() call may lead to a use-after-free.
Vulnerability: GHSA-64gv-qg2v-vxv6
Summary: Array size is not checked in sized-chunks
Aliases: CVE-2020-25793
Severity: HIGH
CWE: CWE-129
Published: 2021-08-25T20:45:04Z

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 From<InlineArray<A, T>>.
Vulnerability: RUSTSEC-2020-0116
Summary: PinSlab<T> and Unordered<T, S> need bounds on their Send/Sync traits
Aliases: CVE-2020-36436
Published: 2020-11-15T12:00:00Z

Affected versions of this crate unconditionally implemented `Send` & `Sync` for types `PinSlab<T>` & `Unordered<T, S>`. This allows sending non-Send types to other threads and concurrently accessing non-Sync types from multiple threads.

This can result in a data race & memory corruption when types that provide internal mutability without synchronization are contained within `PinSlab<T>` or `Unordered<T, S>` and accessed concurrently from multiple threads.

The flaw was corrected in commits 92f40b4 & 6a6c367 by adding trait bound `T: Send` to `Send` impls for `PinSlab<T>` & `Unordered<T, S>` and adding `T: Sync` to `Sync` impls for `PinSlab<T>` & `Unordered<T, S>`.
Vulnerability: GHSA-jf43-3v8j-qwwr
Summary: Data races in multiqueue
Severity: MODERATE
CWE: CWE-362
Published: 2021-08-25T20:59:56Z

Affected versions of multiqueue unconditionally implemented `Send` for types used in queue implementations (`InnerSend<RW, T>`, `InnerRecv<RW, T>`, `FutInnerSend<RW, T>`, `FutInnerRecv<RW, T>`).

This allows users to send non-Send types to other threads, which can lead to data race bugs or other undefined behavior.
Vulnerability: GHSA-8mjx-h23h-w2pg
Summary: Double free in stack_dst
Aliases: CVE-2021-28034
Severity: CRITICAL
CWE: CWE-415
Published: 2021-09-01T18:30:44Z

An issue was discovered in the stack_dst crate before 0.6.1 for Rust. Because of the push_inner behavior, a double free can occur upon a val.clone() panic.
Vulnerability: GHSA-jpwg-6gf5-5vh9
Summary: Out of bounds write in reorder
Aliases: CVE-2021-29942
Severity: HIGH
CWE: CWE-787
Published: 2021-08-25T20:54:10Z

An issue was discovered in the reorder crate through 1.1.0 for Rust. swap_index can return uninitialized values if an iterator returns a len() that is too large.
Vulnerability: RUSTSEC-2020-0141
Summary: MvccRwLock allows data races & aliasing violations
Aliases: CVE-2020-36461
Published: 2020-12-10T12:00:00Z

Affected versions of this crate unconditionally implement Send/Sync for `MvccRwLock`.
This can lead to data races when types that are either `!Send` or `!Sync` (e.g. `Rc<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-8gf5-q9p9-wvmc
Summary: Data race in atomic-option
Aliases: CVE-2020-36219
Severity: MODERATE
CWE: CWE-662
Published: 2021-08-25T20:51:42Z

An issue was discovered in the atomic-option crate through 2020-10-31 for Rust. Because AtomicOption<T> implements Sync unconditionally, a data race can occur.
Vulnerability: GHSA-fc7x-2cmc-8j2g
Summary: Incorrect hash in sha2
Aliases: CVE-2021-45696
Severity: CRITICAL
Published: 2022-01-06T22:10:26Z

An issue was discovered in the sha2 crate 0.9.7 before 0.9.8 for Rust. Hashes of long messages may be incorrect when the AVX2-accelerated backend is used.
Vulnerability: RUSTSEC-2020-0004
Summary: sigstack allocation bug can cause memory corruption or leak
Aliases: CVE-2020-35859
Published: 2020-01-24T12:00:00Z

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

This flaw was resolved by correcting the sigstack allocation logic.
Vulnerability: RUSTSEC-2021-0059
Summary: `aesni` has been merged into the `aes` crate
Published: 2021-04-29T12:00:00Z

Please use the `aes` crate going forward. The new repository location is at:

<https://github.com/RustCrypto/block-ciphers/tree/master/aes>

AES-NI is now autodetected at runtime on `i686`/`x86-64` platforms.
If AES-NI is not present, the `aes` crate will fallback to a constant-time
portable software implementation.

To prevent this fallback (and have absence of AES-NI result in an illegal
instruction crash instead), continue to pass the same RUSTFLAGS which were
previously required for the `aesni` crate to compile:

```
RUSTFLAGS=-Ctarget-feature=+aes,+ssse3
```
Vulnerability: GHSA-q879-9g95-56mx
Summary: Wrong type for `Linker`-define functions when used across two `Engine`s
Aliases: CVE-2021-39219
Severity: MODERATE
CWE: CWE-843
Published: 2021-09-20T19:54:26Z

### Impact

As a Rust library the `wasmtime` crate clearly marks which functions are safe and which are `unsafe`, guaranteeing that if consumers never use `unsafe` then it should not be possible to have memory unsafety issues in their embeddings of Wasmtime. An issue was discovered in the safe API of `Linker::func_*` APIs. These APIs were previously not sound when one `Engine` was used to create the `Linker` and then a different `Engine` was used to create a `Store` and then the `Linker` was used to instantiate a module into that `Store`. Cross-`Engine` usage of functions is not supported in Wasmtime and this can result in type confusion of function pointers, resulting in being able to safely call a function with the wrong type.

Triggering this bug requires using at least two `Engine` values in an embedding and then additionally using two different values with a `Linker` (one at the creation time of the `Linker` and another when instantiating a module with the `Linker`).

It's expected that usage of more-than-one `Engine` in an embedding is relatively rare since an `Engine` is intended to be a globally shared resource, so the expectation is that the impact of this issue is relatively small.

The fix implemented is to change this behavior to `panic!()` in Rust instead of silently allowing it. Using different `Engine` instances with a `Linker` is a programmer bug that `wasmtime` catches at runtime.

### Patches

This bug has been patched and users should upgrade to Wasmtime version 0.30.0.

### Workarounds

If you cannot upgrade Wasmtime and are using more than one `Engine` in your embedding it's recommended to instead use only one `Engine` for the entire program if possible. An `Engine` is designed to be a globally shared resource that is suitable to have only one for the lifetime of an entire process. If using multiple `Engine`s is required then code should be audited to ensure that `Linker` is only used with one `Engine`.

### 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-2020-0157
Summary: Improper Synchronization and Race Condition in vm-memory
Aliases: GHSA-mm4m-qg48-f7wc, CVE-2020-13759
Published: 2020-06-02T12:00:00Z

rust-vmm vm-memory before 0.1.1 and 0.2.x before 0.2.1 allows attackers to cause a denial of service (loss of IP networking) because read_obj and write_obj do not properly access memory. This affects aarch64 (with musl or glibc) and x86_64 (with musl).
Vulnerability: GHSA-jrcf-4jp8-m28v
Summary: miow invalidly assumes the memory layout of std::net::SocketAddr
Aliases: CVE-2020-35921
Severity: MODERATE
CWE: CWE-188
Published: 2021-08-25T20:50:35Z

An issue was discovered in the miow crate before 0.3.6 for Rust. It has false expectations about the std::net::SocketAddr memory representation.
Vulnerability: GHSA-cm8g-544f-p9x9
Summary: Use After Free in rusqlite
Aliases: CVE-2021-45716
Severity: HIGH
CWE: CWE-416
Published: 2022-01-06T22:03:16Z

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. create_collation has a use-after-free.
Vulnerability: RUSTSEC-2020-0012
Summary: Relies on undefined behavior of `char::from_u32_unchecked`
Aliases: CVE-2020-35865
Published: 2020-04-24T12:00:00Z

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

The flaw was corrected in version 2.0.0.
Vulnerability: GHSA-xvcg-2q82-r87j
Summary: Panic mishandled in libpulse-binding
Aliases: CVE-2019-25055
Severity: HIGH
Published: 2022-01-06T22:18:19Z

An issue was discovered in the libpulse-binding crate before 2.6.0 for Rust. It mishandles a panic that crosses a Foreign Function Interface (FFI) boundary.
Vulnerability: GHSA-m9m5-cg5h-r582
Summary: Improper random number generation in nanorand
Aliases: CVE-2020-35926
Severity: CRITICAL
CWE: CWE-338
Published: 2021-08-25T20:50:24Z

An issue was discovered in the nanorand crate before 0.5.1 for Rust. It caused any random number generator (even ChaCha) to return all zeroes because integer truncation was mishandled.
Vulnerability: RUSTSEC-2020-0100
Summary: Double free when calling `sys_info::disk_info` from multiple threads
Aliases: CVE-2020-36434
Published: 2020-05-31T12:00:00Z

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

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

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

## Safer Alternatives:
 - [`sysinfo`](https://crates.io/crates/sysinfo)
Vulnerability: GHSA-5vwc-r48g-wj6c
Summary: Exposure of Resource to Wrong Sphere in abomonation
Aliases: CVE-2021-45708
Severity: HIGH
CWE: CWE-668
Published: 2022-01-06T22:08:22Z

An issue was discovered in the abomonation crate through 2021-10-17 for Rust. Because transmute operations are insufficiently constrained, there can be an information leak or ASLR bypass.
Vulnerability: GHSA-mh6h-f25p-98f8
Summary: Uncontrolled memory consumption in protobuf
Aliases: CVE-2019-15544
Severity: HIGH
CWE: CWE-770
Published: 2021-08-25T20:44:05Z

An issue was discovered in the protobuf crate before 2.6.0 for Rust. Attackers can exhaust all memory via Vec::reserve calls.
Vulnerability: RUSTSEC-2020-0045
Summary: bespoke Cell implementation allows obtaining several mutable references to the same data
Aliases: CVE-2020-35898
Published: 2020-01-08T12:00:00Z

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

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

The flaw was corrected by switching from a bespoke `Cell<T>` implementation to `Rc<RefCell<T>>`.
Vulnerability: RUSTSEC-2019-0038
Summary: Fix for UB in failure to catch panics crossing FFI boundaries
Published: 2019-03-10T12:00:00Z

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

[1]: https://github.com/jnqnfe/pulse-binding-rust/commit/7fd282aef7787577c385aed88cb25d004b85f494
Vulnerability: GHSA-vfqx-hv88-f9cv
Summary: Double-free in id-map
Aliases: CVE-2021-30456
Severity: CRITICAL
CWE: CWE-415
Published: 2021-08-25T20:55:22Z

An issue was discovered in the id-map crate through 2021-02-26 for Rust. A double free can occur in get_or_insert upon a panic of a user-provided f function.
Vulnerability: RUSTSEC-2021-0130
Summary: Use after free in lru crate
Published: 2021-12-21T12:00:00Z

Lru crate has use after free vulnerability.

Lru crate has two functions for getting an iterator. Both iterators give
references to key and value. Calling specific functions, like pop(), will remove
and free the value, and but it's still possible to access the reference of value
which is already dropped causing use after free.
Vulnerability: GHSA-838h-jqp6-cf2f
Summary: Sandbox bypass leading to arbitrary code execution in Deno
Aliases: CVE-2022-24783
Severity: CRITICAL
CWE: CWE-269
Published: 2022-03-29T22:10:10Z

### Impact

The versions of Deno between release 1.18.0 and 1.20.2 (inclusive) are vulnerable to an attack where a malicious actor controlling the code executed in a Deno runtime could bypass permission checks and execute arbitrary shell code.

There is **no** evidence that this vulnerability has been exploited in the wild.

This vulnerability does **not** affect users of Deno Deploy.

### Patches

The vulnerability has been patched in Deno 1.20.3.

### Workarounds

There is no workaround. All users are recommended to upgrade to 1.20.3 immediately

---

The cause of this error was that certain FFI operations did not correctly check for permissions. The issue was fixed in [this](https://github.com/denoland/deno/pull/14115) pull request.
Vulnerability: RUSTSEC-2018-0008
Summary: Bug in SliceDeque::move_head_unchecked allows read of corrupted memory
Aliases: CVE-2018-20995
Published: 2018-12-05T12:00:00Z

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

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

The flaw was corrected by properly updating the head and tail of the deque in
this case.
Vulnerability: RUSTSEC-2021-0075
Summary: Flaw in `FieldVar::mul_by_inverse` allows unsound R1CS constraint systems
Aliases: CVE-2021-38194
Published: 2021-07-08T12:00:00Z

Versions `0.2.0` to `0.3.0` of ark-r1cs-std did not enforce any constraints in the `FieldVar::mul_by_inverse` method, allowing a malicious prover to produce an unsound proof that passes all verifier checks.
This method was used primarily in scalar multiplication for [`short_weierstrass::ProjectiveVar`](https://docs.rs/ark-r1cs-std/0.3.0/ark_r1cs_std/groups/curves/short_weierstrass/struct.ProjectiveVar.html).

This bug was fixed in commit `47ddbaa`, and was released as part of version `0.3.1` on `crates.io`.
Vulnerability: GHSA-c9rv-3jmq-527w
Summary: Unexpected panic when decoding tokens in branca
Aliases: CVE-2020-35918
Severity: MODERATE
CWE: CWE-20
Published: 2021-08-25T20:49:50Z

An issue was discovered in the branca crate before 0.10.0 for Rust. Decoding tokens (with invalid base62 data) can panic.
Vulnerability: GHSA-h45v-vgvp-3h5v
Summary: Out-of-bounds write in stack
Aliases: CVE-2020-35895
Severity: CRITICAL
CWE: CWE-787
Published: 2021-08-25T20:49:13Z

An issue was discovered in the stack crate before 0.3.1 for Rust. ArrayVec has an out-of-bounds write via element insertion.
Vulnerability: GHSA-5xg3-j2j6-rcx4
Summary: Relative Path Traversal in git-delta
Aliases: CVE-2021-36376
Severity: HIGH
CWE: CWE-427, CWE-23
Published: 2021-08-25T21:01:39Z

git-delta before 0.8.3 on Windows resolves an executable's pathname as a relative path from the current directory.
Vulnerability: RUSTSEC-2016-0006
Summary: `cassandra` crate is unmaintained; use `cassandra-cpp` instead
Published: 2016-12-15T12:00:00Z

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

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

https://github.com/Metaswitch/cassandra-rs
Vulnerability: GHSA-h352-g5vw-3926
Summary: Improper Input Validation in fruity
Aliases: CVE-2021-43620
Severity: HIGH
CWE: CWE-20
Published: 2021-11-16T17:26:47Z

An issue was discovered in the fruity crate through 0.2.0 for Rust. Security-relevant validation of filename extensions is plausibly affected. Methods of NSString for conversion to a string may return a partial result. Because they call CStr::from_ptr on a pointer to the string buffer, the string is terminated at the first '\0' byte, which might not be the end of the string.
Vulnerability: RUSTSEC-2021-0022
Summary: Use-after-free in `subscript_next` and `subscript_prev` wrappers
Aliases: CVE-2021-27377
Published: 2021-02-09T12:00:00Z

Affected versions of this crate had an unsound implementation which could pass
a pointer to freed memory to `ydb_subscript_next_st` and
`ydb_subscript_prev_st` if the variable and subscripts did not have enough
memory allocated on the first call to hold the next variable in the database.

For example, the following code had undefined behavior:

```rust
let mut key = Key::variable(String::from("a"));
Key::variable("averylongkeywithlotsofletters")
    .set_st(YDB_NOTTP, Vec::new(), b"some val")
    .unwrap();
key.sub_next_self_st(YDB_NOTTP, Vec::new()).unwrap();
```

`yottadb` has no reverse-dependencies on crates.io and there are no known
instances of this API being used incorrectly in practice. The fix is backwards
compatible.

The flaw was corrected by recalculating the pointer each time it was reallocated.
Vulnerability: GHSA-vcw4-8ph6-7vw8
Summary: Use after free in Rocket
Aliases: CVE-2021-29935
Severity: HIGH
CWE: CWE-416
Published: 2021-08-25T20:54:20Z

An issue was discovered in the rocket crate before 0.4.7 for Rust. uri::Formatter can have a use-after-free if a user-provided function panics.
Vulnerability: RUSTSEC-2019-0014
Summary: Flaw in interface may drop uninitialized instance of arbitrary types
Aliases: CVE-2019-16138
Published: 2019-08-21T12:00:00Z

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

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

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

Starting from version `0.22`, a breaking change to the interface requires
callers to pre-allocate the output buffer and pass a mutable slice instead,
avoiding all unsafe code.
Vulnerability: GHSA-4cww-f7w5-x525
Summary: Stack consumption in trust-dns-server
Aliases: CVE-2020-35857
Severity: HIGH
CWE: CWE-400
Published: 2021-08-25T20:46:13Z

An issue was discovered in the trust-dns-server crate before 0.18.1 for Rust. DNS MX and SRV null targets are mishandled, causing stack consumption.
Vulnerability: RUSTSEC-2020-0069
Summary: Argument injection in sendmail transport
Aliases: CVE-2020-28247
Published: 2020-11-11T12:00:00Z

Affected versions of lettre allowed argument injection
to the sendmail command. It was possible, using forged `to` addresses,
to pass arbitrary arguments to the sendmail executable.

Depending on the implementation (original sendmail, postfix, exim, etc.)
it could be possible in some cases to write email data into arbitrary files (using sendmail's
logging features).
 
The flaw is corrected by modifying the executed command to stop parsing arguments
before passing the destination addresses.

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

This vulnerability was reported by vin01.
Vulnerability: RUSTSEC-2020-0086
Summary: crate has been renamed to `sn_client`
Published: 2020-12-07T12:00:00Z

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

The new repository location is:

<https://github.com/maidsafe/sn_client>
Vulnerability: GHSA-wqxc-qrq4-w5v4
Summary: Update unsound DrainFilter and RString::retain
Aliases: CVE-2020-36213
Severity: HIGH
CWE: CWE-172
Published: 2021-08-25T21:01:33Z

An issue was discovered in the abi_stable crate before 0.9.1 for Rust. A retain call can create an invalid UTF-8 string, violating soundness.
Vulnerability: GHSA-8gmx-cpcg-f8h5
Summary: Double-free in id-map
Aliases: CVE-2021-30455
Severity: CRITICAL
CWE: CWE-415
Published: 2021-08-25T20:55:11Z

An issue was discovered in the id-map crate through 2021-02-26 for Rust. A double free can occur in IdMap::clone_from upon a .clone panic.
Vulnerability: RUSTSEC-2021-0034
Summary: office is unmaintained, use calamine instead
Published: 2021-02-04T12:00:00Z

The `office` crate is unmaintained. Use [calamine](https://crates.io/crates/calamine)
for reading excel files.

Contact the `office` author for ownership of the package name.
Vulnerability: GHSA-368f-29c3-4f2r
Summary: Data race in conqueue
Aliases: CVE-2020-36437
Severity: HIGH
CWE: CWE-119, CWE-362
Published: 2021-08-25T20:58:50Z

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

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

The flaw was corrected in commit 1e462c3 by imposing `T: Send` to both `Send`/`Sync` impls for `QueueSender<T>`/`QueueReceiver<T>`.
Vulnerability: RUSTSEC-2019-0002
Summary: Bug in SliceDeque::move_head_unchecked corrupts its memory
Aliases: CVE-2019-15543
Published: 2019-05-07T12:00:00Z

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

This allows an attacker that controls controls both element insertion and
removal to corrupt the deque, such that reading elements from it would read
bytes corresponding to other elements in the deque. (e.g. a read of T could read
some bytes from one value and some bytes from an adjacent one, resulting in a T
whose value representation is not meaningful). This is undefined behavior.
 
The flaw was corrected by using a pair of pointers to track the head and tail of
the deque instead of a pair of indices. This pair of pointers are represented
using a Rust slice.
Vulnerability: GHSA-9pp4-8p8v-g78w
Summary: Data races in lever
Aliases: CVE-2020-36457
Severity: HIGH
CWE: CWE-77, CWE-362
Published: 2021-08-25T20:57:26Z

An issue was discovered in the lever crate before 0.1.1 for Rust. AtomicBox<T> 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: RUSTSEC-2020-0090
Summary: Thex<T> allows data races of non-Send types across threads
Aliases: CVE-2020-35927
Published: 2020-12-08T12:00:00Z

`thex::Thex<T>` implements `Sync` for all types `T`. However, it is missing a
bound for `T: Send`.

This allows non-Send types such as `Rc` to be sent across thread boundaries
which can trigger undefined behavior and memory corruption.
Vulnerability: GHSA-g4vj-x7v9-h82m
Summary: Overflow in libsecp256k1
Aliases: CVE-2021-38195
Severity: CRITICAL
CWE: CWE-190, CWE-347
Published: 2021-08-25T20:56:03Z

An issue was discovered in the libsecp256k1 crate before 0.5.0 for Rust. It can verify an invalid signature because it allows the R or S parameter to be larger than the curve order, aka an overflow.
Vulnerability: RUSTSEC-2021-0126
Summary: RustEmbed generated `get` method allows for directory traversal when reading files from disk
Published: 2021-11-29T12:00:00Z

When running in debug mode and the `debug-embed` (off by default) feature is
not enabled, the generated `get` method does not check that the input path is
a child of the folder given. 

This allows attackers to read arbitrary files in the file system if they have
control over the filename given. The following code will print the contents of
your `/etc/passwd` if adjusted with a correct number of `../`s depending on
where it is run from.

```rust
#[derive(rust_embed::RustEmbed)]
#[folder = "src/"]
pub struct Asset;

fn main() {
    let d = Asset::get("../../../etc/passwd").unwrap().data;
    println!("{}", String::from_utf8_lossy(&d));
}
```

The flaw was corrected by canonicalizing the input filename and ensuring that
it starts with the canonicalized folder path.
Vulnerability: GHSA-3837-87vh-xq3w
Summary: Data race in v9
Aliases: CVE-2020-36447
Severity: HIGH
CWE: CWE-77
Published: 2021-08-25T20:57:07Z

v9 is a slim data engine for Data Oriented Design. An issue was discovered in the v9 crate through 2020-12-18 for Rust. There is an unconditional implementation of Sync for SyncRef<T>.
Vulnerability: RUSTSEC-2021-0063
Summary: XSS in `comrak`
Aliases: CVE-2021-38186
Published: 2021-05-04T12:00:00Z

[comrak](https://github.com/kivikakk/comrak) operates by default in a "safe"
mode of operation where unsafe content, such as arbitrary raw HTML or URLs with
non-standard schemes, are not permitted in the output.  This is per the
reference GFM implementation, [cmark-gfm](https://github.com/github/cmark).

Ampersands were not being correctly escaped in link targets, making it possible
to fashion unsafe URLs using schemes like `data:` or `javascript:` by entering
them as HTML entities, e.g. `&#x64&#x61&#x74&#x61&#x3a`.  The intended
behaviour, demonstrated upstream, is that these should be escaped and therefore
harmless, but this behaviour was broken in comrak.
Vulnerability: RUSTSEC-2020-0028
Summary: `LocalRequest::clone` creates multiple mutable references to the same object
Aliases: CVE-2020-35882
Published: 2020-05-27T12:00:00Z

The affected version of `rocket` contains a `Clone` trait implementation of
`LocalRequest` that reuses the pointer to inner `Request` object.
This causes data race in rare combinations of APIs if the original and the
cloned objects are modified at the same time.
Vulnerability: GHSA-3vv3-frrq-6486
Summary: Use of Uninitialized Resource in alg_ds
Aliases: CVE-2020-36432
Severity: CRITICAL
CWE: CWE-908, CWE-665
Published: 2021-08-25T20:59:20Z

An issue was discovered in the alg_ds crate through 2020-08-25 for Rust. `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-whc7-5p35-4ww2
Summary: Use after free in actix-service
Aliases: CVE-2020-35899
Severity: MODERATE
CWE: CWE-416
Published: 2021-08-25T20:49:06Z

An issue was discovered in the actix-service crate before 1.0.6 for Rust. The Cell implementation allows obtaining more than one mutable reference to the same data.
Vulnerability: GHSA-fqpx-cq8x-9wp4
Summary: Unaligned references in sized-chunks
Aliases: CVE-2020-25796
Severity: HIGH
CWE: CWE-129
Published: 2021-08-25T20:46:03Z

An issue was discovered in the sized-chunks crate through 0.6.2 for Rust. In the InlineArray implementation, an unaligned reference may be generated for a type that has a large alignment requirement.
Vulnerability: GHSA-hj9h-wrgg-hgmx
Summary: Data races in lock_api
Aliases: CVE-2020-35913
Severity: MODERATE
CWE: CWE-362
Published: 2021-08-25T20:50:02Z

An issue was discovered in the lock_api crate before 0.4.2 for Rust. A data race can occur because of RwLockReadGuard unsoundness.
Vulnerability: RUSTSEC-2019-0022
Summary: Stream callback function is not unwind safe
Aliases: CVE-2019-16881
Published: 2019-09-14T12:00:00Z

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

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

This allows an attacker to construct an arbitrary code execution .
 
The flaw was reported by Phosphorus15.
Vulnerability: GHSA-9xjr-m6f3-v5wm
Summary: HTTPS MitM vulnerability due to lack of hostname verification
Aliases: CVE-2016-10932
Severity: MODERATE
CWE: CWE-347
Published: 2021-08-25T20:43:06Z

An issue was discovered in the hyper crate before 0.9.4 for Rust on Windows. There is an HTTPS man-in-the-middle vulnerability because hostname verification was omitted.
Vulnerability: GHSA-5h46-h7hh-c6x9
Summary: Integer Overflow in Chunked Transfer-Encoding
Aliases: CVE-2021-32714
Severity: MODERATE
CWE: CWE-190
Published: 2021-07-12T16:55:37Z

### Summary

hyper's HTTP server and client code had a flaw that could trigger an integer overflow when decoding chunk sizes that are too big. This allows possible data loss, or if combined with an upstream HTTP proxy that allows chunk sizes larger than hyper does, can result in "request smuggling" or "desync attacks".

### Vulnerability

Example:

```
GET / HTTP/1.1
Host: example.com
Transfer-Encoding: chunked

f0000000000000003
abc
0

```

hyper only reads the rightmost 64-bit integer as the chunk size. So it reads `f0000000000000003` as `3`. A loss of data can occur since hyper would then read only 3 bytes of the body. Additionally, an HTTP request smuggling vulnerability would occur if using a proxy which instead has prefix truncation in the chunk size, or that understands larger than 64-bit chunk sizes.

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

### Impact

To determine if vulnerable to _data loss_, these things must be true:

- **Using HTTP/1.1.** Since HTTP/2 does not use chunked encoding, it is not vulnerable.
- **Using hyper as a server or client.** The body would be improperly truncated in either case.
- **Users send requests or responses with chunk sizes greater than 18 exabytes**.

To determine if vulnerable to _desync attacks_, these things must be true:

- **Using an upstream proxy that allows chunks sizes larger than 64-bit.** If the proxy rejects chunk sizes that are too large, that request won't be forwarded to hyper.

### Patches

We have released the following patch versions:

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

### Workarounds

Besides upgrading hyper, you can take the following options:

- Reject requests manually that contain a `Transfer-Encoding` header.
- Ensure any upstream proxy rejects `Transfer-Encoding` chunk sizes greater than what fits in 64-bit unsigned integers.


### Credits
This issue was initially reported by [Mattias Grenfeldt](https://grenfeldt.dev/) and Asta Olofsson.
Vulnerability: GHSA-9658-c26v-7qvf
Summary: Use-after-free in yottadb
Aliases: CVE-2021-27377
Severity: CRITICAL
CWE: CWE-416
Published: 2021-08-25T20:55:30Z

An issue was discovered in the yottadb crate before 1.2.0 for Rust. For some memory-allocation patterns, ydb_subscript_next_st and ydb_subscript_prev_st have a use-after-free.
Vulnerability: RUSTSEC-2021-0014
Summary: Record::read : Custom `Read` on uninitialized buffer may cause UB
Aliases: CVE-2021-26308
Published: 2021-01-26T12:00:00Z

Affected versions of this crate passes an uninitialized buffer to a user-provided `Read` implementation. (`Record::read()`)

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.

This flaw was fixed in commit 6299af0 by zero-initializing the newly allocated memory (via `data.resize(len, 0)`) instead of exposing uninitialized memory (`unsafe { data.set_len(len) }`).
Vulnerability: GHSA-8gjm-h3xj-mp6w
Summary: RPC call failure in ckb
Aliases: CVE-2021-45698
Severity: CRITICAL
Published: 2022-01-06T22:10:43Z

An issue was discovered in the ckb crate before 0.40.0 for Rust. A get_block_template RPC call may fail in situations where it is supposed to select a Nervos CKB blockchain transaction with a higher fee rate than another transaction.
Vulnerability: GHSA-5wg8-7c9q-794v
Summary: Data races in lock_api
Aliases: CVE-2020-35912
Severity: MODERATE
CWE: CWE-362
Published: 2021-08-25T20:50:00Z

An issue was discovered in the lock_api crate before 0.4.2 for Rust. A data race can occur because of MappedRwLockWriteGuard unsoundness.