TQRG/raw-osv-data huggingface dataset:
Vulnerability: GHSA-m3ww-7hrp-gw9w
Summary: Drop of uninitialized memory in Ozone
Aliases: CVE-2020-35878
Severity: CRITICAL
CWE: CWE-908, CWE-119
Published: 2021-08-25T20:47:41Z

An issue was discovered in the ozone crate through 2020-07-04 for Rust. Memory safety is violated because of the dropping of uninitialized memory.
Vulnerability: GHSA-87xh-9q6h-r5cc
Summary: Use After Free in rusqlite
Aliases: CVE-2021-45715
Severity: HIGH
CWE: CWE-416
Published: 2022-01-06T22:00:49Z

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_window_function has a use-after-free.
Vulnerability: GHSA-gwc9-348x-qwv2
Summary: Use after free in Wasmtime
Aliases: CVE-2022-24791
Severity: HIGH
CWE: CWE-416
Published: 2022-04-01T13:36:12Z

There is a use after free vulnerability in Wasmtime when both running Wasm that uses `externref`s and enabling [epoch interruption](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.epoch_interruption) in Wasmtime. If you are not explicitly enabling epoch interruption (it is disabled by default) then you are not affected. If you are explicitly disabling the Wasm reference types proposal (it is enabled by default) then you are also not affected.

The use after free is caused by Cranelift failing to emit stack maps when there are safepoints inside cold blocks. Cold blocks occur when epoch interruption is enabled. Cold blocks are emitted at the end of compiled functions, and change the order blocks are emitted versus defined. This reordering accidentally caused Cranelift to skip emitting some stack maps because it expected to emit the stack maps in block definition order, rather than block emission order. When Wasmtime would eventually collect garbage, it would fail to find live references on the stack because of the missing stack maps, think that they were unreferenced garbage, and therefore reclaim them. Then after the collection ended, the Wasm code could use the reclaimed-too-early references, which is a use after free.

This bug was discovered while extending our fuzz targets for `externref`s and GC in Wasmtime. The updated fuzz target thoroughly exercises these code paths and feature combinations now. We have also added a regression test for this bug. Released versions 0.34.2 and 0.35.2, which fix the vulnerability. We recommend all Wasmtime users upgrade to these patched versions. If upgrading is not an option for you at this time, you can avoid the vulnerability by either disabling the Wasm reference types proposal or by disabling epoch interruption if you were previously enabling it.
Vulnerability: GHSA-gh87-6jr3-8q47
Summary: Null pointer deference in cache
Aliases: CVE-2021-25903
Severity: HIGH
CWE: CWE-476
Published: 2021-08-25T20:52:57Z

An issue was discovered in the cache crate through 2021-01-01 for Rust. A raw pointer is dereferenced.
Vulnerability: RUSTSEC-2020-0135
Summary: Slock<T> allows sending non-Send types across thread boundaries
Aliases: CVE-2020-36455
Published: 2020-11-17T12:00:00Z

`Slock<T>` unconditionally implements `Send`/`Sync`.

Affected versions of this crate allows sending non-Send types to other threads,
which can lead to data races and memory corruption due to the data race.
Vulnerability: GHSA-45w7-7g63-2m5w
Summary: Drop of uninitialized memory in stack_dst
Aliases: CVE-2021-28035
Severity: CRITICAL
CWE: CWE-908
Published: 2021-09-01T18:30:55Z

Affected versions of stack_dst used a push_inner function that increased the internal length of the array and then called val.clone(). If the val.clone() call panics, the stack could drop an already dropped element or drop uninitialized memory. This issue was fixed in 2a4d538 by increasing the length of the array after elements are cloned.
Vulnerability: RUSTSEC-2020-0070
Summary: Some lock_api lock guard objects can cause data races
Aliases: CVE-2020-35914, CVE-2020-35911, CVE-2020-35913, CVE-2020-35910, CVE-2020-35912
Published: 2020-11-08T12:00:00Z

Affected versions of lock_api had unsound implementations of the `Send` or
`Sync` traits for some guard objects, namely:

* MappedMutexGuard
* MappedRwLockReadGuard
* MappedRwLockWriteGuard
* RwLockReadGuard
* RwLockWriteGuard

These guards could allow data races through types that are not safe to `Send`
across thread boundaries in safe Rust code.

This issue was fixed by changing the trait bounds on the `Mapped` guard types
and removing the `Sync` trait for the `RwLock` guards.
Vulnerability: GHSA-8c6g-4xc5-w96c
Summary: Uninitialized memory exposure in claxon
Aliases: CVE-2018-20992
Severity: MODERATE
CWE: CWE-908
Published: 2021-08-25T20:43:52Z

An issue was discovered in the claxon crate before 0.4.1 for Rust. Uninitialized memory can be exposed because certain decode buffer sizes are mishandled.
Vulnerability: GHSA-9p8q-j6q5-mjw8
Summary: Buffer Overflow in galois_2p8
Aliases: CVE-2022-24988
Severity: CRITICAL
CWE: CWE-120
Published: 2022-02-15T00:02:45Z

In galois_2p8 before 0.1.2, PrimitivePolynomialField::new has an off-by-one buffer overflow for a vector.
Vulnerability: RUSTSEC-2017-0003
Summary: Hostname verification skipped when custom root certs used
Aliases: CVE-2017-18588
Published: 2017-03-15T12:00:00Z

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

This issue was fixed by properly configuring the trust evaluation logic to
perform that check.
Vulnerability: RUSTSEC-2020-0162
Summary: `tokio-proto` is deprecated/unmaintained
Published: 2020-02-06T12:00:00Z

The [`tokio-proto`](https://crates.io/crates/tokio-proto) crate has been deprecated, and [its GitHub repository](https://github.com/tokio-rs/tokio-proto) has been archived.
Users may be interested in [`tokio-tower`](https://crates.io/crates/tokio-tower) instead, per https://github.com/tokio-rs/tokio/issues/118#issuecomment-452969665
Vulnerability: RUSTSEC-2020-0027
Summary: traitobject assumes the layout of fat pointers
Aliases: CVE-2020-35881
Published: 2020-06-01T12:00:00Z

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

This has been fixed in the master branch of the crate, but is has not
been released into crates.io.
Vulnerability: GHSA-q9h2-4xhf-23xx
Summary: Data races in im
Aliases: CVE-2020-36204
Severity: MODERATE
CWE: CWE-662
Published: 2021-08-25T20:51:36Z

An issue was discovered in the im crate through 2020-11-09 for Rust. Because TreeFocus does not have bounds on its Send trait or Sync trait, a data race can occur.
Vulnerability: RUSTSEC-2018-0011
Summary: Enum repr causing potential memory corruption
Aliases: CVE-2018-20998
Published: 2018-12-18T12:00:00Z

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

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

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

The issue was fixed in crate 3.6.0.
Vulnerability: RUSTSEC-2021-0083
Summary: QueryInterface should call AddRef before returning pointer
Published: 2021-01-20T12:00:00Z

Affected version of this crate, which is a required dependency in com-impl, 
provides a faulty implementation of the `IUnknown::QueryInterface` method.

`QueryInterface` implementation must call `IUnknown::AddRef` before returning the pointer,
as describe in this documentation:
<https://docs.microsoft.com/en-us/windows/win32/api/unknwn/nf-unknwn-iunknown-queryinterface(refiid_void)>

As it is not incrementing the refcount as expected, the following calls to `IUnknown::Release` method 
will cause WMI to drop reference to the interface, and can lead to invalid reference.

This is documented in <https://docs.microsoft.com/en-us/windows/win32/learnwin32/managing-the-lifetime-of-an-object#reference-counting>

There is no simple workaround, as you can't know how many time QueryInterface will be called.
The only way to quick fix this is to use the macro expanded version of the code and modify 
the QueryInterface method to add the AddRef call yourself.

The issue was corrected in commit `9803f31fbd1717d482d848f041044d061fca6da7`.
Vulnerability: GHSA-fg42-vwxx-xx5j
Summary: Data race in tiny_future
Aliases: CVE-2020-36438
Severity: HIGH
CWE: CWE-119, CWE-362
Published: 2021-08-25T20:58:53Z

An issue was discovered in the tiny_future crate before 0.4.0 for Rust. Future<T> does not have bounds on its Send and Sync traits.
Vulnerability: RUSTSEC-2021-0129
Summary: Invalid handling of `X509_verify_cert()` internal errors in libssl
Aliases: CVE-2021-4044
Published: 2021-12-14T12:00:00Z

Internally libssl in OpenSSL calls `X509_verify_cert()` on the client side to
verify a certificate supplied by a server. That function may return a negative
return value to indicate an internal error (for example out of memory). Such a
negative return value is mishandled by OpenSSL and will cause an IO function
(such as `SSL_connect()` or `SSL_do_handshake()`) to not indicate success and a
subsequent call to `SSL_get_error()` to return the value
`SSL_ERROR_WANT_RETRY_VERIFY`. This return value is only supposed to be returned
by OpenSSL if the application has previously called
`SSL_CTX_set_cert_verify_callback()`. Since most applications do not do this the
`SSL_ERROR_WANT_RETRY_VERIFY` return value from `SSL_get_error()` will be totally
unexpected and applications may not behave correctly as a result. The exact
behaviour will depend on the application but it could result in crashes,
infinite loops or other similar incorrect responses.

This issue is made more serious in combination with a separate bug in OpenSSL
3.0 that will cause `X509_verify_cert()` to indicate an internal error when
processing a certificate chain. This will occur where a certificate does not
include the Subject Alternative Name extension but where a Certificate Authority
has enforced name constraints. This issue can occur even with valid chains.
Vulnerability: GHSA-v5r6-6r3c-wqxc
Summary: Memory exhaustion in asn1_der
Aliases: CVE-2019-15549
Severity: HIGH
CWE: CWE-400
Published: 2021-08-25T20:44:56Z

An issue was discovered in the asn1_der crate before 0.6.2 for Rust. Attackers can trigger memory exhaustion by supplying a large value in a length field.
Vulnerability: GHSA-c7fw-cr3w-wvfc
Summary: Data races in arr
Aliases: CVE-2020-35886
Severity: MODERATE
CWE: CWE-362
Published: 2021-08-25T20:49:04Z

An issue was discovered in the arr crate through 2020-08-25 for Rust. An attacker can smuggle non-Sync/Send types across a thread boundary to cause a data race.
Vulnerability: RUSTSEC-2020-0050
Summary: VecCopy allows misaligned access to elements
Aliases: CVE-2020-35903
Published: 2020-09-27T12:00:00Z

`VecCopy::data` is created as a Vec of u8 but can be used to store and retrieve
elements of different types leading to misaligned access.

The issue was resolved in v0.5.0 by replacing data being stored by `Vec<u8>` with a custom managed
pointer.  Elements are now stored and retrieved using types with proper alignment corresponding to
original types.
Vulnerability: RUSTSEC-2020-0115
Summary: Singleton lacks bounds on Send and Sync.
Aliases: CVE-2020-36435
Published: 2020-11-16T12:00:00Z

`Singleton<T>` is meant to be a static object that can be initialized lazily. In
order to satisfy the requirement that `static` items must implement `Sync`,
`Singleton` implemented both `Sync` and `Send` unconditionally.

This allows for a bug where non-`Sync` types such as `Cell` can be used in
singletons and cause data races in concurrent programs.

The flaw was corrected in commit `b0d2bd20e` by adding trait bounds, requiring
the contaiend type to implement `Sync`.
Vulnerability: GHSA-gwfj-pw2x-h6c2
Summary: Out of bounds read in simd-json
Aliases: CVE-2019-15550
Severity: HIGH
CWE: CWE-125
Published: 2021-08-25T20:43:56Z

An issue was discovered in the simd-json crate before 0.1.15 for Rust. There is an out-of-bounds read and an incorrect crossing of a page boundary.
Vulnerability: GHSA-36cg-4jff-5863
Summary: Data races in signal-simple
Aliases: CVE-2020-36446
Severity: HIGH
CWE: CWE-119, CWE-362
Published: 2021-08-25T20:59:13Z

An issue was discovered in the signal-simple crate through 2020-11-15 for Rust. There are unconditional implementations of Send and Sync for SyncChannel<T>.
Vulnerability: RUSTSEC-2021-0109
Summary: Process crashes when the cell used as DepGroup is not alive
Aliases: GHSA-45p7-c959-rgcm
Published: 2021-07-25T12:00:00Z

It's easy to create a malign transaction which uses the dead cell as the DepGroup in the DepCells. The transaction can crash all the receiving nodes.
Vulnerability: GHSA-7v2r-wxmg-mgvc
Summary: HTTP Request smuggling in tiny_http
Aliases: CVE-2020-35884
Severity: MODERATE
CWE: CWE-444
Published: 2021-08-25T20:48:56Z

An issue was discovered in the tiny_http crate through 2020-06-16 for Rust. HTTP Request smuggling can occur via a malformed Transfer-Encoding header.
Vulnerability: RUSTSEC-2020-0007
Summary: use-after or double free of allocated memory
Aliases: CVE-2020-35862
Published: 2020-03-27T12:00:00Z

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

The flaw was corrected by using the address after resizing, rather than the original base address.
Vulnerability: GHSA-pq6v-x7gp-7776
Summary: Source code is downloaded over cleartext HTTP in portaudio
Aliases: CVE-2016-10933
Severity: MODERATE
CWE: CWE-319
Published: 2021-08-25T20:43:09Z

An issue was discovered in the portaudio crate through 0.7.0 for Rust. There is a man-in-the-middle issue because the source code is downloaded over cleartext HTTP.
Vulnerability: RUSTSEC-2020-0142
Summary: Send bound needed on T (for Send impl of `Bucket2`)
Aliases: CVE-2020-36462
Published: 2020-11-29T12:00:00Z

Affected versions of this crate unconditionally implements `Send` for `Bucket2`. This allows sending non-Send types to other threads.

This can lead to data races when non Send types like `Cell<T>` or `Rc<T>` are contained inside `Bucket2` and sent across thread boundaries. The data races can potentially lead to memory corruption (as demonstrated in the PoC from the original report issue).

The flaw was corrected in commit 15b2828 by adding a `T: Send` bound to the `Send` impl of `Bucket2<T>`.
Vulnerability: GHSA-jjx5-3f36-6927
Summary: Incorrect buffer size calculation in iced-x86
Aliases: CVE-2021-38188
Severity: CRITICAL
CWE: CWE-131
Published: 2021-08-25T20:55:47Z

An issue was discovered in the iced-x86 crate through 1.10.3 for Rust. In Decoder::new(), slice.get_unchecked(slice.length()) is used unsafely.
Vulnerability: RUSTSEC-2020-0011
Summary: Library exclusively intended to obfuscate code.
Published: 2020-04-23T12:00:00Z

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

The value this adds is questionable, and hides `unsafe` usages from naive analysis.
Vulnerability: GHSA-hc92-9h3m-c39j
Summary: Incorrect cast in anymap
Aliases: CVE-2021-38187
Severity: CRITICAL
CWE: CWE-681, CWE-704
Published: 2021-08-25T20:55:45Z

An issue was discovered in the anymap crate through 0.12.1 for Rust. It violates soundness via conversion of a *u8 to a *u64.
Vulnerability: RUSTSEC-2020-0154
Summary: InputStream::read_exact : `Read` on uninitialized buffer causes UB
Published: 2020-12-31T12: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-v3j6-xf77-8r9c
Summary: Use-after-free in actix-http
Aliases: CVE-2020-35901
Severity: HIGH
CWE: CWE-416
Published: 2021-08-25T20:49:39Z

An issue was discovered in the actix-http crate before 2.0.0-alpha.1 for Rust. There is a use-after-free in BodyStream.
Vulnerability: GHSA-wv4p-jp67-jr97
Summary: Data races in magnetic
Aliases: CVE-2020-35925
Severity: MODERATE
CWE: CWE-362
Published: 2021-08-25T20:50:05Z

An issue was discovered in the magnetic crate before 2.0.1 for Rust. MPMCConsumer and MPMCProducer allow cross-thread sending of a non-Send type.
Vulnerability: GHSA-8r7q-r9mx-35rh
Summary: Mishandling of format strings in rusqlite
Aliases: CVE-2020-35869
Severity: CRITICAL
CWE: CWE-134
Published: 2021-08-25T20:47:18Z

An issue was discovered in the rusqlite crate before 0.23.0 for Rust. Memory safety can be violated because rusqlite::trace::log mishandles format strings.
Vulnerability: RUSTSEC-2020-0046
Summary: bespoke Cell implementation allows obtaining several mutable references to the same data
Aliases: CVE-2020-35899
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: GHSA-3cj3-jrrp-9rxf
Summary: Unchecked Return Value in xcb
Aliases: CVE-2021-26958
Severity: HIGH
CWE: CWE-252
Published: 2021-08-25T20:53:18Z

An issue was discovered in the xcb crate through 2021-02-04 for Rust. It has a soundness violation because transmutation to the wrong type can happen after xcb::base::cast_event uses std::mem::transmute to return a reference to an arbitrary type.
Vulnerability: GHSA-6hfq-h8hq-87mf
Summary: HTTP Request Smuggling in hyper
Aliases: CVE-2021-21299
Severity: MODERATE
CWE: CWE-444
Published: 2021-08-25T20:56:18Z

### Summary

hyper's HTTP server code had a flaw that incorrectly understands some requests with multiple transfer-encoding headers to have a chunked payload, when it should have been rejected as illegal. This combined with an upstream HTTP proxy that understands the request payload boundary differently can result in "request smuggling" or "desync attacks".

### Vulnerability

The flaw was introduced in https://github.com/hyperium/hyper/commit/26417fc24a7d05df538e0f39239b373c5c3d61f6, released in v0.12.0.

Consider this example request:

```
POST /yolo HTTP/1.1
Transfer-Encoding: chunked
Transfer-Encoding: cow
```

This request *should* be rejected, according to RFC 7230, since it has a `Transfer-Encoding` header, but after folding, it does not end in `chunked`. hyper would notice the `chunked` in the first line, and then check the second line, and thanks to a missing boolean assignment, *not* set the error condition. hyper would treat the payload as being `chunked`. By differing from the spec, it is possible to send requests like these to endpoints that have different HTTP implementations, with different interpretations of the payload semantics, and cause "desync attacks".

There are several parts of the spec that must also be checked, and hyper correctly handles all of those. Additionally, hyper's *client* does not allow sending requests with improper headers, so the misunderstanding cannot be propagated further.

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

### Impact

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

- **Using hyper as an HTTP *server*.** The client is not affected.
- **Using HTTP/1.1.** HTTP/2 does not use `transfer-encoding`.
- **Using a vulnerable HTTP proxy upstream to hyper.** If an upstream proxy correctly rejects the illegal transfer-encoding headers, the desync attack cannot succeed. If there is *no* proxy upstream of hyper, hyper cannot *start* the desync attack, as the client will repair the headers before forwarding.

### Patches

We have released and backported the following patch versions:

- v0.14.3
- v0.13.10

### Workarounds

Besides upgrading hyper, you can take the following options:

- Reject requests that contain a `transfer-encoding` header.
- Ensure any upstream proxy handles `transfer-encoding` correctly.

### Credits

This issue was initially reported by ZeddYu Lu From Qi An Xin Technology Research Institute.
Vulnerability: GHSA-vp6r-mrq9-8f4h
Summary: Data race in syncpool
Aliases: CVE-2020-36462
Severity: HIGH
CWE: CWE-77, CWE-362
Published: 2021-08-25T20:58:11Z

An issue was discovered in the syncpool crate before 0.1.6 for Rust. There is an unconditional implementation of Send for Bucket2.
Vulnerability: RUSTSEC-2020-0103
Summary: `impl Random` on arrays can lead to dropping uninitialized memory
Aliases: CVE-2020-36210
Published: 2020-12-31T12:00:00Z

Affected versions of this crate had a panic safety issue to drop partially uninitialized array of `T` upon panic in a user provided function `T::random()`. Dropping uninitialized `T` can potentially cause memory corruption or undefined behavior.

The flaw was corrected in commit 565d508 by using `MaybeUninit<T>` to avoid possible dropping of uninitialized memory upon panic.
Vulnerability: GHSA-gvvv-w559-2hg6
Summary: Data races in scottqueue
Aliases: CVE-2020-36453
Severity: HIGH
CWE: CWE-362
Published: 2021-08-25T20:57:17Z

An issue was discovered in the scottqueue crate through 2020-11-15 for Rust. There are unconditional implementations of Send and 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: RUSTSEC-2021-0076
Summary: libsecp256k1 allows overflowing signatures
Aliases: CVE-2021-38195
Published: 2021-07-13T12:00:00Z

libsecp256k1 accepts signatures whose R or S parameter is larger than the
secp256k1 curve order, which differs from other implementations. This could
lead to invalid signatures being verified.

The error is resolved in 0.5.0 by adding a `check_overflow` flag.
Vulnerability: GHSA-77m6-x95j-75r5
Summary: Data races in ticketed_lock
Aliases: CVE-2020-36439
Severity: HIGH
CWE: CWE-119, CWE-362
Published: 2021-08-25T20:58:58Z

An issue was discovered in the ticketed_lock crate before 0.3.0 for Rust. There are unconditional implementations of Send for ReadTicket<T> and WriteTicket<T>.
Vulnerability: GHSA-fg7r-2g4j-5cgr
Summary: Race Condition in tokio
Aliases: CVE-2021-45710
Severity: HIGH
CWE: CWE-362
Published: 2022-01-06T22:04:37Z

An issue was discovered in the tokio crate before 1.8.4, and 1.9.x through 1.13.x before 1.13.1, for Rust. In certain circumstances involving a closed oneshot channel, there is a data race and memory corruption.
Vulnerability: RUSTSEC-2021-0099
Summary: Crate has been renamed to `cosmrs`
Published: 2021-08-25T12:00:00Z

The `cosmos_sdk` crate, which provides a basic Rust SDK for the Cosmos ecosystem,
has rebranded to “CosmRS” in the spirit of other projects like CosmJS and CosmWasm.

You can find the new home here:

https://github.com/cosmos/cosmos-rust/tree/main/cosmrs

The new crate name is `cosmrs`:

https://crates.io/crates/cosmrs
Vulnerability: RUSTSEC-2021-0133
Summary: cargo-download is unmaintained
Published: 2021-12-25T12:00:00Z

The cargo download subcommand (via cargo-download crate) is broken and maintainer has disappeared from GitHub and hasn't had any commits for a year. 

Using this downloader will result to corrupted crates.

Maintainer has not responded to maintenance takeover.

Just use wget / curl directly.
Vulnerability: GHSA-9qvw-46gf-4fv8
Summary: Use After Free in tremor-script
Aliases: CVE-2021-45702
Severity: HIGH
CWE: CWE-416
Published: 2022-01-06T22:09:07Z

An issue was discovered in the tremor-script crate before 0.11.6 for Rust. A merge operation may result in a use-after-free.
Vulnerability: GHSA-x446-3xhq-5xfp
Summary: Exposure of Resource to Wrong Sphere in Simple-Wayland-HotKey-Daemon
Aliases: CVE-2022-27814
Severity: LOW
CWE: CWE-668
Published: 2022-04-15T00:00:40Z

SWHKD 1.1.5 allows arbitrary file-existence tests via the -c option.
Vulnerability: GHSA-458v-4hrf-g3m4
Summary: socket2 invalidly assumes the memory layout of std::net::SocketAddr
Aliases: CVE-2020-35920
Severity: MODERATE
CWE: CWE-188
Published: 2021-08-25T20:50:37Z

The socket2 crate has assumed `std::net::SocketAddrV4` and `std::net::SocketAddrV6` have the same memory layout as the system C representation `sockaddr`. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the memory layout, and this will cause invalid memory access if the standard library changes the implementation. No warnings or errors will be emitted once the change happens.
Vulnerability: RUSTSEC-2021-0021
Summary: `nb-connect` invalidly assumes the memory layout of std::net::SocketAddr
Aliases: CVE-2021-27376
Published: 2021-02-14T12:00:00Z

The [`nb-connect`](https://crates.io/crates/nb-connect) crate has assumed `std::net::SocketAddrV4`
and `std::net::SocketAddrV6` have the same memory layout as the system C representation
`sockaddr`. It has simply casted the pointers to convert the socket addresses to the
system representation. The standard library does not say anything about the memory
layout, and this will cause invalid memory access if the standard library
changes the implementation. No warnings or errors will be emitted once the
change happens.
Vulnerability: GHSA-vc5p-j8vw-mc6x
Summary: Permissions bypass in pleaser
Aliases: CVE-2021-31155
Severity: HIGH
CWE: CWE-269, CWE-279
Published: 2021-08-25T21:01:47Z

Failure to normalize the umask in pleaser before 0.4 allows a local attacker to gain full root privileges if they are allowed to execute at least one command.
Vulnerability: RUSTSEC-2020-0085
Summary: crate has been renamed to `sn_node`
Published: 2020-12-07T12:00:00Z

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

The new repository location is:

<https://github.com/maidsafe/sn_node>
Vulnerability: GHSA-f6f2-3w33-54r9
Summary: Use After Free in rusqlite
Aliases: CVE-2021-45714
Severity: HIGH
CWE: CWE-416
Published: 2022-01-06T22:02:36Z

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_aggregate_function has a use-after-free.
Vulnerability: RUSTSEC-2019-0017
Summary: Panic during initialization of Lazy<T> might trigger undefined behavior
Aliases: CVE-2019-16141
Published: 2019-09-01T12:00:00Z

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

Applications with `panic = "abort"` are not affected, as there will be no
subsequent dereferences.
Vulnerability: RUSTSEC-2021-0037
Summary: Fix a use-after-free bug in diesels Sqlite backend
Aliases: CVE-2021-28305
Published: 2021-03-05T12:00:00Z

We've misused `sqlite3_column_name`. The
[SQLite](https://www.sqlite.org/c3ref/column_name.html) documentation
states that the following:

> The returned string pointer is valid until either the prepared statement
> is destroyed by sqlite3_finalize() or until the statement is automatically
> reprepared by the first call to sqlite3_step() for a particular
> run or until the next call to sqlite3_column_name()
> or sqlite3_column_name16() on the same column.

As part of our `query_by_name` infrastructure we've first received all
field names for the prepared statement and stored them as string slices
for later use. After that we called `sqlite3_step()` for the first time,
which invalids the pointer and therefore the stored string slice.
Vulnerability: GHSA-3358-4f7f-p4j4
Summary: Use after free in generic-array
Aliases: CVE-2020-36465
Severity: HIGH
CWE: CWE-416
Published: 2021-08-25T20:56:12Z

An issue was discovered in the generic-array crate before 0.13.3 for Rust. It violates soundness by using the arr! macro to extend lifetimes.
Vulnerability: GHSA-6mv9-qcx2-3hh3
Summary: Memory exhaustion in routinator
Aliases: CVE-2021-43174
Severity: HIGH
CWE: CWE-787
Published: 2021-11-11T00:55:08Z

NLnet Labs Routinator versions 0.9.0 up to and including 0.10.1, support the gzip transfer encoding when querying RRDP repositories. This encoding can be used by an RRDP repository to cause an out-of-memory crash in these versions of Routinator. RRDP uses XML which allows arbitrary amounts of white space in the encoded data. The gzip scheme compresses such white space extremely well, leading to very small compressed files that become huge when being decompressed for further processing, big enough that Routinator runs out of memory when parsing input data waiting for the next XML element.
Vulnerability: GHSA-r7rv-2rph-hvhj
Summary: Improper synchronization in buttplug
Aliases: CVE-2020-36218
Severity: MODERATE
CWE: CWE-662
Published: 2021-08-25T20:51:45Z

An issue was discovered in the buttplug crate before 1.0.4 for Rust. ButtplugFutureStateShared does not properly consider (!Send|!Sync) objects, leading to a data race.
Vulnerability: RUSTSEC-2020-0139
Summary: dces' World type can cause data races
Aliases: CVE-2020-36459
Published: 2020-12-09T12:00:00Z

The `World` type in `dces` is marked as `Send` without bounds on its
`EntityStore` and `ComponentStore`.

This allows non-thread safe `EntityStore` and `ComponentStore`s to be sent
across threads and cause data races.
Vulnerability: GHSA-v938-qcc9-rwv8
Summary: Use of Uninitialized Resource in buffoon.
Aliases: CVE-2020-36512
Severity: CRITICAL
CWE: CWE-908
Published: 2022-01-06T22:17:09Z

An issue was discovered in the buffoon crate through 2020-12-31 for Rust. InputStream::read_exact may read from uninitialized memory locations.
Vulnerability: RUSTSEC-2020-0093
Summary: Async-h1 request smuggling possible with long unread bodies
Aliases: GHSA-4vr9-8cjf-vf9c, CVE-2020-26281, CVE-2020-36202
Published: 2020-12-17T12:00:00Z

This vulnerability affects any webserver that uses async-h1 behind a reverse proxy, including all such Tide applications.

If the server does not read the body of a request which is longer than some buffer length, async-h1 will attempt to read a subsequent request from the body content starting at that offset into the body.

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

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

The flaw was corrected in commit [7df79f](https://github.com/http-rs/async-h1/commit/7df79f1d5d99fc0f492b315eebc7f0d301a85212) by ensuring that the request body is always consumed from the tcp stream before attempting to read subsequent keep-alive request headers from it.
Vulnerability: RUSTSEC-2019-0001
Summary: Uncontrolled recursion leads to abort in HTML serialization
Aliases: CVE-2019-15542
Published: 2019-04-27T12:00:00Z

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

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

The flaw was corrected by serializing the DOM tree iteratively instead.
Vulnerability: GHSA-6vmq-jh76-hq43
Summary: Uninitialized memory access in outer_cgi
Aliases: CVE-2021-30454
Severity: CRITICAL
CWE: CWE-119
Published: 2021-08-25T20:55:25Z

An issue was discovered in the outer_cgi crate before 0.2.1 for Rust. A user-provided Read instance receives an uninitialized memory buffer from KeyValueReader.
Vulnerability: GHSA-wgx2-6432-j3fw
Summary: Unsoundness in bigint
Aliases: CVE-2020-35880
Severity: CRITICAL
CWE: CWE-704
Published: 2021-08-25T20:48:04Z

An issue was discovered in the bigint crate through 2020-05-07 for Rust. It allows a soundness violation.
Vulnerability: RUSTSEC-2021-0060
Summary: `aes-soft` 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 force the use of a constant-time portable implementation on these platforms,
even if AES-NI is available, use the new `force-soft` feature of the `aes`
crate to disable autodetection.
Vulnerability: RUSTSEC-2021-0125
Summary: Panic on incorrect date input to `simple_asn1`
Published: 2021-11-14T12:00:00Z

Version 0.6.0 of the `simple_asn1` crate panics on certain malformed
inputs to its parsing functions, including `from_der` and `der_decode`.
Because this crate is frequently used with inputs from the network, this
should be considered a security vulnerability.

The issue occurs when parsing the old ASN.1 "UTCTime" time format.  If an
attacker provides a UTCTime where the first character is ASCII but the
second character is above 0x7f, a string slice operation in the
`from_der_` function will try to slice into the middle of a UTF-8
character, and cause a panic.

This error was introduced in commit
[`d7d39d709577710e9dc8`](https://github.com/acw/simple_asn1/commit/d7d39d709577710e9dc8833ee57d200eef366db8),
which updated `simple_asn1` to use `time` instead of `chrono` because of
[`RUSTSEC-2020-159`](https://rustsec.org/advisories/RUSTSEC-2020-0159).
Versions of `simple_asn1` before 0.6.0 are not affected by this issue.

The [patch](https://github.com/acw/simple_asn1/pull/28) was applied in
`simple_asn1` version 0.6.1.
Vulnerability: GHSA-pvh2-pj76-4m96
Summary: Specification non-compliance in JUMPI
Aliases: CVE-2021-41153
Severity: HIGH
CWE: CWE-670
Published: 2021-10-19T15:28:35Z

### Impact 

In `evm` crate `< 0.31.0`, `JUMPI` opcode's condition is checked after the destination validity check. However, according to Geth and OpenEthereum, the condition check should happen before the destination validity check.

### Patches

This is a **high** severity security advisory if you use `evm` crate for Ethereum mainnet. In this case, you should update your library dependency immediately to on or after `0.31.0`.

This is a **low** severity security advisory if you use `evm` crate in Frontier or in a standalone blockchain, because there's no security exploit possible with this advisory. It is **not** recommended to update to on or after `0.31.0` until all the normal chain upgrade preparations have been done. If you use Frontier or other `pallet-evm` based Substrate blockchain, please ensure to update your `spec_version` before updating this. For other blockchains, please make sure to follow a hard-fork process before you update this.

### Workarounds

If you are dependent on an older version of `evm` and cannot update due to API interface changes, please contact Wei by email (wei@that.world), who will be happy to help you to publish patch releases for older `evm` versions.

### References

Fix PR: https://github.com/rust-blockchain/evm/pull/67

### For more information

If you have any questions or comments about this advisory:
* Open an issue in the `evm` repo.

### Special thanks

Special thanks to @rakita for reporting this issue.
Vulnerability: GHSA-hv7x-f3pv-gpwr
Summary: Wrong memory orderings violates mutual exclusion in spin
Aliases: CVE-2019-16137
Severity: HIGH
CWE: CWE-662
Published: 2021-08-25T20:44:46Z

An issue was discovered in the spin crate before 0.5.2 for Rust, when RwLock is used. Because memory ordering is mishandled, two writers can acquire the lock at the same time, violating mutual exclusion.
Vulnerability: GHSA-rpcm-whqc-jfw8
Summary: Use after free in libflate
Aliases: CVE-2019-15552
Severity: CRITICAL
CWE: CWE-416
Published: 2021-08-25T20:44:53Z

An issue was discovered in the libflate crate before 0.1.25 for Rust. MultiDecoder::read has a use-after-free, leading to arbitrary code execution.
Vulnerability: RUSTSEC-2021-0061
Summary: `aes-ctr` 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>

The `aes` crate now has an optional `ctr` feature which autodetects SIMD
features on `i686`/`x86-64` targets and uses them if available, or otherwise
falls back to the implementation in the `ctr` crate.

If you would prefer not to have this autodetection performed, use the `aes`
crate directly with the `ctr` crate.
Vulnerability: RUSTSEC-2021-0124
Summary: Data race when sending and receiving after closing a `oneshot` channel
Aliases: CVE-2021-45710
Published: 2021-11-16T12:00:00Z

If a `tokio::sync::oneshot` channel is closed (via the
[`oneshot::Receiver::close`] method), a data race may occur if the
`oneshot::Sender::send` method is called while the corresponding
`oneshot::Receiver` is `await`ed or calling `try_recv`.

When these methods are called concurrently on a closed channel, the two halves
of the channel can concurrently access a shared memory location, resulting in a
data race. This has been observed to [cause memory corruption][corruption].

Note that the race only occurs when **both** halves of the channel are used
after the `Receiver` half has called `close`. Code where `close` is not used, or where the
`Receiver` is not `await`ed and `try_recv` is not called after calling `close`,
is not affected.

See [tokio#4225][issue] for more details.

[corruption]: https://github.com/tokio-rs/tokio/issues/4225#issuecomment-967434847
[issue]: https://github.com/tokio-rs/tokio/issues/4225
[`oneshot::Receiver::close`]: https://docs.rs/tokio/1.14.0/tokio/sync/oneshot/struct.Receiver.html#method.close
Vulnerability: RUSTSEC-2020-0138
Summary: ReaderResult should be bounded by Sync
Aliases: CVE-2020-36458
Published: 2020-11-10T12:00:00Z

Affected versions of this crate implements `Sync` for `ReaderResult<T, E>` with the trait bound `T: Send, E: Send`.

Since matching on the public enum `ReaderResult<T, E>` provides access to `&T` & `&E`,
allowing data race to a non-Sync type `T` or `E`.
This can result in a memory corruption when multiple threads concurrently access `&T` or `&E`.

Suggested fix for the bug is change the trait bounds imposed on `T` & `E` to be `T: Sync, E: Sync`.
Vulnerability: RUSTSEC-2020-0092
Summary: Send/Sync bound needed on V in `impl Send/Sync for ARCache<K, V>`
Aliases: CVE-2020-35928
Published: 2020-11-13T12:00:00Z

Affected versions of this crate unconditionally implemented `Send`/`Sync` traits for `ARCache<K, V>` type.

This allows users to send/access types that do not implement `Send`/`Sync`, which can cause a data race.

The flaw was corrected in the 0.2.6 release by adding bounds `K: Send + Sync` & `V: Send + Sync` to affected `Send`/`Sync` trait implementations.
Vulnerability: RUSTSEC-2021-0036
Summary: Intern<T>: Data race allowed on T
Aliases: CVE-2021-28037
Published: 2021-03-03T12:00:00Z

Affected versions of this crate unconditionally implements `Sync` for `Intern<T>`.
This allows users to create data race on `T: !Sync`, which may lead to undefined behavior
(for example, memory corruption).

The flaw was corrected in commit 2928a87 by adding the trait bound `T: Sync` in the `Sync` impl of `Intern<T>`.
Vulnerability: GHSA-x4qm-mcjq-v2gf
Summary: Overflow in prost-types
Aliases: CVE-2021-38192
Severity: HIGH
CWE: CWE-190, CWE-120
Published: 2021-08-25T20:55:53Z

An issue was discovered in the prost-types crate before 0.8.0 for Rust. An overflow can occur during conversion from Timestamp to SystemTime.
Vulnerability: GHSA-pf3p-x6qj-6j7q
Summary: mio invalidly assumes the memory layout of std::net::SocketAddr
Aliases: CVE-2020-35922
Severity: MODERATE
CWE: CWE-188
Published: 2021-08-25T20:50:33Z

An issue was discovered in the mio crate before 0.7.6 for Rust. It has false expectations about the std::net::SocketAddr memory representation.
Vulnerability: RUSTSEC-2020-0084
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-2019-0016
Summary: Use-after-free in buffer conversion implementation
Aliases: CVE-2019-16140
Published: 2019-09-01T12:00:00Z

The From<Buffer> implementation for Vec<u8> was not properly implemented,
returning a vector backed by freed memory. This could lead to memory corruption
or be exploited to cause undefined behavior.
 
A fix was published in version 0.1.3.
Vulnerability: RUSTSEC-2021-0020
Summary: Multiple Transfer-Encoding headers misinterprets request payload
Aliases: CVE-2021-21299, GHSA-6hfq-h8hq-87mf
Published: 2021-02-05T12:00:00Z

hyper's HTTP server code had a flaw that incorrectly understands some requests
with multiple transfer-encoding headers to have a chunked payload, when it
should have been rejected as illegal. This combined with an upstream HTTP proxy
that understands the request payload boundary differently can result in
"request smuggling" or "desync attacks".
Vulnerability: GHSA-4xj5-vv9x-63jp
Summary: Data races in concread
Aliases: CVE-2020-35928
Severity: MODERATE
CWE: CWE-362
Published: 2021-08-25T20:50:22Z

An issue was discovered in the concread crate before 0.2.6 for Rust. Attackers can cause an ARCache<K,V> data race by sending types that do not implement Send/Sync.
Vulnerability: RUSTSEC-2016-0004
Summary: libusb is unmaintained; use rusb instead
Published: 2016-09-10T12:00:00Z

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

The `rusb` crate is a maintained fork:

https://github.com/a1ien/rusb
Vulnerability: RUSTSEC-2021-0077
Summary: `better-macro` has deliberate RCE to prove a point
Aliases: CVE-2021-38196
Published: 2021-07-22T12:00:00Z

[better-macro](https://crates.io/crates/better-macro) is a fake crate which is
"Proving A Point" that proc-macros can run arbitrary code. This is not a particularly
novel or interesting observation.

It currently opens `https://github.com/raycar5/better-macro/blob/master/doc/hi.md`
which doesn't appear to have any malicious content, but there's no guarantee that
will remain the case.

This crate has no useful functionality, and should not be used.
Vulnerability: GHSA-gx73-2498-r55c
Summary: Unsound casting in flatbuffers
Aliases: CVE-2019-25004
Severity: CRITICAL
CWE: CWE-704
Published: 2021-08-25T20:46:49Z

An issue was discovered in the flatbuffers crate before 0.6.1 for Rust. Arbitrary bytes can be reinterpreted as a bool, defeating soundness.
Vulnerability: RUSTSEC-2021-0098
Summary: Read buffer overruns processing ASN.1 strings
Aliases: CVE-2021-3712
Published: 2021-08-24T12:00:00Z

ASN.1 strings are represented internally within OpenSSL as an ASN1_STRING
structure which contains a buffer holding the string data and a field holding
the buffer length. This contrasts with normal C strings which are represented as
a buffer for the string data which is terminated with a NUL (0) byte.

Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL's
own "d2i" functions (and other similar parsing functions) as well as any string
whose value has been set with the ASN1_STRING_set() function will additionally
NUL terminate the byte array in the ASN1_STRING structure.

However, it is possible for applications to directly construct valid ASN1_STRING
structures which do not NUL terminate the byte array by directly setting the
"data" and "length" fields in the ASN1_STRING array. This can also happen by
using the `ASN1_STRING_set0()` function.

Numerous OpenSSL functions that print ASN.1 data have been found to assume that
the ASN1_STRING byte array will be NUL terminated, even though this is not
guaranteed for strings that have been directly constructed. Where an application
requests an ASN.1 structure to be printed, and where that ASN.1 structure
contains ASN1_STRINGs that have been directly constructed by the application
without NUL terminating the "data" field, then a read buffer overrun can occur.

The same thing can also occur during name constraints processing of certificates
(for example if a certificate has been directly constructed by the application
instead of loading it via the OpenSSL parsing functions, and the certificate
contains non NUL terminated ASN1_STRING structures). It can also occur in the
`X509_get1_email()`, `X509_REQ_get1_email()` and `X509_get1_ocsp()` functions.

If a malicious actor can cause an application to directly construct an
ASN1_STRING and then process it through one of the affected OpenSSL functions
then this issue could be hit. This might result in a crash (causing a Denial of
Service attack). It could also result in the disclosure of private memory
contents (such as private keys, or sensitive plaintext).
Vulnerability: RUSTSEC-2021-0132
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.

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.
Vulnerability: RUSTSEC-2020-0047
Summary: array_queue pop_back() may cause a use-after-free
Aliases: CVE-2020-35900
Published: 2020-09-26T12:00:00Z

array_queue implements a circular queue that wraps around an array. However, it
fails to properly index into the array in the `pop_back` function allowing the
reading of previously dropped or uninitialized memory.
Vulnerability: RUSTSEC-2020-0102
Summary: LateStatic has incorrect Sync bound
Aliases: CVE-2020-36209
Published: 2020-11-10T12:00:00Z

Affected versions of this crate implemented `Sync` for `LateStatic` with `T: Send`, so that it is possible to create a data race to a type `T: Send + !Sync` (e.g. `Cell<T>`).

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

The flaw was corrected in commit 11f396c by replacing the `T: Send` bound to `T: Sync` bound in the `Sync` impl for `LateStatic<T>`.
Vulnerability: GHSA-p2q9-9cq6-h3jw
Summary: Out of bounds read in Ozone
Aliases: CVE-2020-35877
Severity: CRITICAL
CWE: CWE-119
Published: 2021-08-25T20:47:46Z

An issue was discovered in the ozone crate through 2020-07-04 for Rust. Memory safety is violated because of out-of-bounds access.
Vulnerability: RUSTSEC-2020-0010
Summary: tiberius is unmaintained
Published: 2020-02-28T12:00:00Z

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

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

Suggested alternatives are:

- [`odbc`](https://crates.io/crates/odbc)
- [`sqlx`](https://github.com/launchbadge/sqlx/issues/116) (forthcoming)
Vulnerability: GHSA-jqjj-r4qp-x2gh
Summary: Use of Uninitialized Resource in messagepack-rs.
Aliases: CVE-2021-45693
Severity: CRITICAL
CWE: CWE-908
Published: 2022-01-06T22:12:42Z

An issue was discovered in the messagepack-rs crate through 2021-01-26 for Rust. deserialize_string_primitive may read from uninitialized memory locations.
Vulnerability: GHSA-r2x6-vrxx-jgv4
Summary: Data races in multiqueue
Aliases: CVE-2020-36463
Severity: HIGH
CWE: CWE-77, CWE-362
Published: 2021-08-25T20:58:07Z

An issue was discovered in the multiqueue crate through 2020-12-25 for Rust. There are unconditional implementations of Send for InnerSend<RW, T>, InnerRecv<RW, T>, FutInnerSend<RW, T>, and FutInnerRecv<RW, T>.
Vulnerability: RUSTSEC-2020-0155
Summary: `Read` on uninitialized buffer in `fill_buf()` and `read_up_to()`
Published: 2020-12-27T12: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.