deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-2969-8hh9-57jc
Package: ckb (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 0.40.0
Patched in: 0.40.0

Summary: Allocation of Resources Without Limits or Throttling in ckb

Details:
An issue was discovered in the ckb crate before 0.40.0 for Rust. Remote attackers may be able to conduct a 51% attack against the Nervos CKB blockchain by triggering an inability to allocate memory for the misbehavior HashMap.
GitHub Security Advisory: GHSA-8gjm-h3xj-mp6w
Package: ckb (RUST)
Severity: CRITICAL (CVSS 9.8)
Vulnerable versions: < 0.40.0
Patched in: 0.40.0

Summary: RPC call failure in ckb

Details:
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.
GitHub Security Advisory: GHSA-cw98-cx2m-9qqg
Package: ckb (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: < 0.40.0
Patched in: 0.40.0

Summary: Denial of Service in ckb

Details:
An issue was discovered in the ckb crate before 0.40.0 for Rust. Attackers can cause a denial of service (Nervos CKB blockchain node crash) via a dead call that is used as a DepGroup.
GitHub Security Advisory: GHSA-qwvx-c8j7-5g75
Package: tectonic_xdv (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-908: Use of Uninitialized Resource
Vulnerable versions: < 0.1.12
Patched in: 0.1.12

Summary: Use of Uninitialized Resource in tectonic_xdv

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

The problem was fixed in commit `cdff034` by zero-initializing the buffer before passing it to a user-provided Read implementation.
GitHub Security Advisory: GHSA-cwvc-87xq-pc5m
Package: metrics-util (RUST)
Severity: HIGH (CVSS 8.1)
CWE: CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'), CWE-787: Out-of-bounds Write
Vulnerable versions: < 0.7.0
Patched in: 0.7.0

Summary: Out-of-bounds Write and Race Condition in metrics-util

Details:
In the affected versions of the crate, AtomicBucket<T> unconditionally implements Send/Sync traits. Therefore, users can create a data race to the inner T: !Sync by using the AtomicBucket::data_with() API. Such data races can potentially cause memory corruption or other undefined behavior.

The flaw was fixed in commit 8e6daab by adding appropriate Send/Sync bounds to the Send/Sync impl of struct Block<T> (which is a data type contained inside AtomicBucket<T>).
GitHub Security Advisory: GHSA-c5hx-w945-j4pq
Package: zeroize_derive (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-459: Incomplete Cleanup
Vulnerable versions: < 1.1.1
Patched in: 1.1.1

Summary: Memory flaw in zeroize_derive

Details:
An issue was discovered in the zeroize_derive crate before 1.1.1 for Rust. Dropped memory is not zeroed out for an enum.
GitHub Security Advisory: GHSA-5vwc-r48g-wj6c
Package: abomonation (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-668: Exposure of Resource to Wrong Sphere
Vulnerable versions: <= 0.7.3
Patched in: unpatched

Summary: Abomonation transmutes &T to and from &[u8] without sufficient constraints

Details:
An issue was discovered in the abomonation crate through version 0.7.3 for Rust. Because transmute operations are insufficiently constrained, there can be an information leak or ASLR bypass.
GitHub Security Advisory: GHSA-g4h2-4wvh-grc5
Package: simple_asn1 (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: = 0.6.0
Patched in: 0.6.1

Summary: Uncontrolled Resource Consumption in simple_asn1

Details:
An issue was discovered in the simple_asn1 crate 0.6.0 before 0.6.1 for Rust. There is a panic if UTCTime data, supplied by a remote attacker, has a second character greater than 0x7f.
GitHub Security Advisory: GHSA-xrg3-hmf3-rvgw
Package: rust-embed (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 6.3.0
Patched in: 6.3.0

Summary: Path Traversal in rust-embed

Details:
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.
GitHub Security Advisory: GHSA-gjrj-9rj4-pgwx
Package: perseus-actix-web (RUST)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: <= 0.3.0-beta.21
Patched in: 0.3.0-beta.22

Summary: DoS Vulnerability from Upstream Actix Web Issues

Details:
### Impact
This vulnerability affects all users of the `perseus deploy` functionality who have not exported their sites to static files. If you are using the inbuilt Perseus server in production, there is a memory leak in Actix Web stemming from [this upstream issue](https://github.com/actix/actix-web/issues/1780) which can allow even a single user to cause the process to exhaust its memory on low-memory servers by continuously reloading the page. Note that this issue does not affect all Actix Web applications, but rather results from certain usage patterns which appear to be present in Perseus' server mechanics.

### Patches
This vulnerability is addressed in all versions after Perseus `v0.3.0-beta.21`, which temporarily discontinues the use of `perseus-actix-web` (until the upstream bug is fixed) and switches to `perseus-warp` instead, which utilizes [Warp](https://github.com/seanmonstar/warp).

Additionally, as of Perseus `v0.3.0-beta.22`, the Actix Web integration has been upgraded to use the latest unstable beta version of Actix Web, which appears to partially resolve this issue (the severity of the memory leak is reduced). However, due to the instability of this version, the default integration will remain Warp for now, and a warning will appear if you attempt to use the Actix Web integration.

<details>
<summary>Using the Actix Web integration</summary>

If the instability of the latest beta version of Actix Web is not a concern for you, you can use this integration by adding `-i actix-web` to `perseus serve` and the like. This will print a warning about instability, and will then operate with the beta version. Please report any failures in functionality that are not security-related to the Perseus team by [opening an issue on the repository](https://github.com/arctic-hen7/perseus/issues/new/choose).

Note however that switching to the Warp integration requires no code changes whatsoever unless you've ejected, so there are very few disadvantages to this change.

</details>

### Workarounds
Due to significant infrastructural changes within other Perseus packages that were needed to support Warp, this integration is not backward-compatible with any previous version of Perseus, meaning there are no easily feasible workarounds. If you're only in development though, this vulnerability is irrelevant until you push to production.

### CVE Status

Due to GitHub's requirements, a CVE can't be issued for this security advisory because the issue is technically one with Actix Web (though it's only in combination with certain mechanics in the Perseus server that this problem arises).

### References
See [this upstream issue](https://github.com/actix/actix-web/issues/1780) in Actix Web.

### For more information
If you have any questions or comments about this advisory:
* Open an issue on this repository
* Email me at [arctic_hen7@pm.me](mailto:arctic_hen7@pm.me)
GitHub Security Advisory: GHSA-hf79-8hjp-rrvq
Package: lucet-runtime (RUST)
Severity: HIGH (CVSS 8.5)
CWE: CWE-416: Use After Free
Vulnerable versions: <= 0.6.1
Patched in: unpatched

Summary: Use After Free in lucet

Details:
### Impact
There is a bug in the main branch of Lucet's `lucet-runtime` that allows a use-after-free in an `Instance` object that could result in memory corruption, data race, or other related issues.  This bug was introduced early in the development of Lucet and is present in all releases.  As a result of this bug, and dependent on the memory backing for the `Instance` objects, it is possible to trigger a use-after-free when the `Instance` is dropped.

### Patches
Users should upgrade to the `main` branch of the Lucet repository. Lucet does not provide versioned releases on crates.io.

### Workarounds
There is no way to remediate this vulnerability without upgrading.

### Description
Lucet uses a "pool" allocator for new WebAssembly instances that are created. This pool allocator manages everything from the linear memory of the wasm instance, the runtime stack for async switching, as well as the memory behind the Instance itself. `Instances` are referred to via an `InstanceHandle` type which will, on drop, release the memory backing the Instance back to the pool.

When an Instance is dropped, the fields of the `Instance` are destructed top-to-bottom, however when the `alloc: Alloc` field is destructed, the memory backing the `Instance` is released back to the pool before the destructors of the remaining fields are run. If another thread allocates the same memory from the pool while these destructors are still running, a race condition occurs that can lead to use-after-free errors.

The bug was corrected by changing how the `InstanceHandle` destructor operates to ensure that the memory backing an Instance is only returned to the pool once the `Instance` has been completely destroyed.

This security advisory has been assigned CVE-2021-43790.

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [lucet repository](https://github.com/bytecodealliance/lucet)
* Email [the lucet team](mailto:lucet@fastly.com)
* See the [Bytecode Alliance security policy](https://bytecodealliance.org/security)
GitHub Security Advisory: GHSA-6mv9-qcx2-3hh3
Package: routinator (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-787: Out-of-bounds Write
Vulnerable versions: >= 0.9.0, < 0.10.2
Patched in: 0.10.2

Summary: Memory exhaustion in routinator

Details:
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.
GitHub Security Advisory: GHSA-862g-9h5m-m3qv
Package: coreos-installer (RUST)
Severity: MODERATE (CVSS 5.5)
CWE: CWE-276: Incorrect Default Permissions
Vulnerable versions: < 0.10.0
Patched in: 0.10.0

Summary: coreos-installer < 0.10.0 writes world-readable Ignition config to installed system

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

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

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

### Workarounds

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

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

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

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

### For more information
If you have any questions or comments about this advisory, [open an issue in coreos-installer](https://github.com/coreos/coreos-installer/issues/new/choose) or email the CoreOS [development mailing list](https://lists.fedoraproject.org/archives/list/coreos@lists.fedoraproject.org/).
GitHub Security Advisory: GHSA-v935-pqmr-g8v9
Package: num-bigint (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-20: Improper Input Validation, CWE-131: Incorrect Calculation of Buffer Size
Vulnerable versions: >= 0.4.1, < 0.4.3
Patched in: 0.4.3

Summary: Unexpected panics in num-bigint

Details:
### Impact

Two scenarios were reported where `BigInt` and `BigUint` multiplication may unexpectedly panic.

- The internal `mac3` function did not expect the possibility of non-empty all-zero inputs, leading to an `unwrap()` panic.
- A buffer was allocated with less capacity than needed for an intermediate result, leading to an assertion panic.

Rust panics can either cause stack unwinding or program abort, depending on the application configuration. In some settings, an unexpected panic may constitute a denial-of-service vulnerability.

### Patches
Both problems were introduced in version 0.4.1, and are fixed in version 0.4.3.

### For more information
If you have any questions or comments about this advisory, please open an issue in the [num-bigint](https://github.com/rust-num/num-bigint) repo.

### Acknowledgements
Thanks to Guido Vranken and Arvid Norberg for privately reporting these issues to the author.

### References
* [GHSA-v935-pqmr-g8v9](https://github.com/rust-num/num-bigint/security/advisories/GHSA-v935-pqmr-g8v9)
* [num-bigint#228](https://github.com/rust-num/num-bigint/pull/228)
GitHub Security Advisory: GHSA-r56q-vv3c-6g9c
Package: tough (RUST)
Severity: HIGH (CVSS 8.2)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 0.12.0
Patched in: 0.12.0

Summary: Improper sanitization of delegated role names

Details:
### Impact
The tough library, prior to 0.12.0, does not properly sanitize delegated role names when caching a repository, or when loading a repository from the filesystem. When the repository is cached or loaded, files ending with the .json extension could be overwritten with role metadata anywhere on the system.

AWS would like to thank https://github.com/jku for reporting this issue.

### Patches
A fix is available in version 0.12.0.

### Workarounds
No workarounds to this issue are known.

### References
https://github.com/theupdateframework/python-tuf/security/advisories/GHSA-wjw6-2cqr-j4qr
GitHub Security Advisory: GHSA-x3r5-q6mj-m485
Package: tough (RUST)
Severity: HIGH (CVSS 8.2)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 0.12.0
Patched in: 0.12.0

Summary: Improper sanitization of target names

Details:
### Impact
The tough library, prior to 0.12.0, does not properly sanitize target names when caching a repository, or when saving specific targets to an output directory. When targets are cached or saved, files could be overwritten with arbitrary content anywhere on the system.

AWS would like to thank https://github.com/jku for reporting this issue.

### Patches
A fix is available in version 0.12.0.

### Workarounds
No workarounds to this issue are known.
GitHub Security Advisory: GHSA-pvh2-pj76-4m96
Package: evm (RUST)
Severity: HIGH (CVSS 8.7)
CWE: CWE-670: Always-Incorrect Control Flow Implementation
Vulnerable versions: < 0.31.0
Patched in: 0.31.0

Summary: Specification non-compliance in JUMPI

Details:
### 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.
GitHub Security Advisory: GHSA-4vr9-8cjf-vf9c
Package: async-h1 (RUST)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')
Vulnerable versions: < 2.3.0
Patched in: 2.3.0

Summary: Async-h1 request smuggling possible with long unread bodies

Details:
### Impact
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.


### Patches
This has been addressed in async-h1 2.3.0 and previous versions have been yanked.

### Workarounds
none

### References
https://github.com/http-rs/async-h1/releases/tag/v2.3.0

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [async-h1](https://github.com/http-rs/async-h1)
* Contact a core team member on [zulip](https://http-rs.zulip-chat.com) or [discord](https://discord.gg/x2gKzst)
GitHub Security Advisory: GHSA-mmc9-pwm7-qj5w
Package: rand_core (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-704: Incorrect Type Conversion or Cast
Vulnerable versions: >= 0.4.0, < 0.4.2
Patched in: 0.4.2

Summary: Unaligned memory access in rand_core

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

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

### Workarounds
None.

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

### For more information
If you have any questions or comments about this advisory, [open an issue in the Rand repository](https://github.com/rust-random/rand/issues/new/choose).
GitHub Security Advisory: GHSA-xpwj-7v8q-mcgj
Package: deno (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-285: Improper Authorization, CWE-863: Incorrect Authorization
Vulnerable versions: >= 1.5.0, <= 1.10.1
Patched in: 1.10.2

Summary: Deno's static imports inside dynamically imported modules do not adhere to permission checks

Details:
### Impact

Modules that are dynamically imported through `import()` or `new Worker` might have been able to bypass network and file system permission checks when statically importing other modules. In Deno 1.5.x and 1.6.x only programs dynamically importing (especially transitively) untrusted code are affected. In Deno 1.7.x all programs importing (especially transitively) untrusted code are affected.

In effect an attacker in control of a (possibly remote) module in a programs module graph has been able to, **irrespective of permissions**:
1. initiate GET requests to arbitrary URLs on the internet (including LAN) and possibly read (parts of) the contents of these resources.
2. check for existence of arbitrary paths on the file system, and possibly read (parts of) the contents of these files.

In Deno 1.5.x (October 27th, 2020) and Deno 1.6.x (December 8th, 2020) the attacker module had to have been granted permissions to load dynamically through the network / fs read permission. Since Deno 1.7.x (January 19th, 2021) this vulnerability was able to be exploited in a fully sandboxed isolate (without any permissions). This vulnerability was not present in releases prior to 1.5.0.

Arbitrary non-GET requests, control over request headers, or file system writes are not possible through this vulnerability. Users of the `deno_core`, `deno_runtime`, or other `deno_*` crates are not affected. This is a Deno CLI only vulnerability.

We are relatively confident this was not abused in the wild, as by default Deno prints out a green "Download" message when remote imports are downloaded, and this would have caused suspicion if it occurred in the middle of a programs execution. This message can be silenced with the `--quiet` flag.  

### Patches

The vulnerability has been patched in Deno release 1.10.2. You can upgrade to the latest Deno version by running the `deno upgrade` command. The release is available through all official download channels. 

### Workarounds

There is no workaround for this issue.

### For more information

If you have any questions or comments about this advisory:
* Open an issue on [the issue tracker](https://github.com/denoland/deno)
* Discuss on [Discord](https://discord.gg/deno)
GitHub Security Advisory: GHSA-w65j-g6c7-g3m4
Package: actix-web (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Vulnerable versions: < 0.7.15
Patched in: 0.7.15

Summary: Multiple memory safety issues in actix-web

Details:
Affected versions contain multiple memory safety issues, such as:

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

This may result in a variety of memory corruption scenarios, most likely use-after-free.
 
A signficant refactoring effort has been conducted to resolve these issues.