deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-c2f5-jxjv-2hh8
Package: wasmtime (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-67: Improper Handling of Windows Device Names, CWE-184: Incomplete List of Disallowed Inputs
Vulnerable versions: < 24.0.2
Patched in: 24.0.2

Summary: Wasmtime doesn't fully sandbox all the Windows device filenames

Details:
### Impact

Wasmtime's filesystem sandbox implementation on Windows blocks access to special device filenames such as "COM1", "COM2", "LPT0", "LPT1", and so on, however it did not block access to the special device filenames which use superscript digits, such as "COM¹", "COM²", "LPT⁰", "LPT¹", and so on. Untrusted Wasm programs that are given access to any filesystem directory could bypass the sandbox and access devices through those special device filenames with superscript digits, and through them gain access peripheral devices connected to the computer, or network resources mapped to those devices. This can include modems, printers, network printers, and any other device connected to a serial or parallel port, including emulated USB serial ports.

### Patches

Patch releases for Wasmtime have been issued as 24.0.2, 25.0.3, and 26.0.1. Users of Wasmtime 23.0.x and prior are recommended to upgrade to one of these patched versions.

### Workarounds

There are no known workarounds for this issue. Affected Windows users are recommended to upgrade.

### References

 - [Microsoft's documentation](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions) of the special device filenames
 - [ISO-8859-1](https://en.wikipedia.org/wiki/ISO/IEC_8859-1)
 - [The original PR reporting the issue](https://github.com/bytecodealliance/cap-std/pull/371)
GitHub Security Advisory: GHSA-7vm6-qwh5-9x44
Package: loona-hpack (RUST)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-754: Improper Check for Unusual or Exceptional Conditions, CWE-755: Improper Handling of Exceptional Conditions
Vulnerable versions: <= 0.4.2
Patched in: 0.4.3

Summary: loona-hpack Panic Vulnerability

Details:
### Summary
`loona-hpack` suffers from the same vulnerability as the original `hpack` as documented in https://github.com/mlalic/hpack-rs/issues/11 

### Details
The original includes a very nice description of the problem, as well as an easy-enough fix for it.

### PoC
The original example pretty much still applies:
```rust
use loona_hpack::Decoder;

pub fn main() {
    let input = &[0x3f];
    let mut decoder = Decoder::new();
    let _ = decoder.decode(input);
}
```

### Impact
From the original:
`All users who try to decode untrusted input using the Decoder are vulnerable to this exploit. A patched version of the crate is available on [crates.io](https://crates.io/crates/hpack-patched) under the name hpack-patched. See [Cargo's documentation on overriding dependencies](https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html) for more information.`
GitHub Security Advisory: GHSA-f77q-r5qm-w4m8
Package: sp1-recursion-gnark-ffi (RUST)
Severity: MODERATE (CVSS 5.3)
Vulnerable versions: < 1.2.0
Patched in: 1.2.0

Summary: sp1-recursion-gnark-ffi has insufficient range checks of BabyBear arithmetic 

Details:
The Gnark recursion circuit constrains arithmetic over BabyBear when the native field of the ZKP circuit is the BN254 scalar field. Proper implementation of this logic requires range checking Bn254 values to be less than the BabyBear modulus.

In versions < 1.2.0, functions like `InvF` and `InvE` used values generated by hints that were not appropriately range checked. These issues are resolved in versions 1.2.0 and higher, by adding range checks in the appropriate places. This code was covered under the original audit scope of the recursion circuit audit by Veridise, and both Veridise and Kalos revisited the code for similar issues and found no additional vulnerabilities.

This issue was discovered by the Succinct team on September 3rd. The issue was fixed and resolved within 48 hours, and released with V1.2.0 (note that a later V2.0.0 release has the same contents as V1.2.0 to respect semver), with production SP1 users being notified and upgraded immediately. The V1.1.0 verifier was frozen on September 4th to ensure that no one uses versions of SP1 with this bug.
GitHub Security Advisory: GHSA-v57h-6hmh-g2p4
Package: pallet-ethereum (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-682: Incorrect Calculation
Vulnerable versions: <= 3.0.0
Patched in: unpatched

Summary: Weight not properly refunded after EVM execution

Details:
### Impact

Previously, the worst case weight was always accounted as the block weight for all cases. In case of large EVM gas refunds, this can lead to block spamming attacks -- the adversary can construct blocks with transactions that have large amount of refunds or unused gases with reverts, and as a result inflate up the chain gas prices. This issue is fixed by properly refund unused weights after each EVM execution.

The impact of this issue is limited in that the spamming attack would still be costly for any adversary, and it has no ability to alter any chain state. 

### Patches

The issue is fixed in https://github.com/paritytech/frontier/pull/851

### Workarounds

None.

### References
_Are there any links users can visit to find out more?_

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [Frontier repo](https://github.com/paritytech/frontier/issues)
* Email [Wei](mailto:wei@that.world)
GitHub Security Advisory: GHSA-vj62-g63v-f8mf
Package: pallet-ethereum (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: <= 3.0.0
Patched in: unpatched

Summary: Validity check missing in Frontier

Details:
### Impact

In the newly introduced signed Frontier-specific extrinsic for `pallet-ethereum`, a large part of transaction validation logic was only called in transaction pool validation, but not in block execution. Malicious validators can take advantage of this to put invalid transactions into a block.

The attack is limited in that the signature is always validated, and the majority of the validation is done again in the subsequent `pallet-evm` execution logic. However, do note that a chain ID replay attack was possible. In addition, spamming attacks are of main concerns, while they are limited by Substrate block size limits and other factors.

### Patches

The issue is patched in commit 146bb48849e5393004be5c88beefe76fdf009aba.

### References

Patch PR: https://github.com/paritytech/frontier/pull/495

### For more information

If you have any questions or comments about this advisory:
* Open an issue in [Frontier repo](https://github.com/paritytech/frontier/issues)

### Special thanks

Special thanks to @librelois, @nanocryk and the Moonbeam team for reporting and fixing this security vulnerability.
GitHub Security Advisory: GHSA-cjg2-2fjg-fph4
Package: pallet-evm-precompile-modexp (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-191: Integer Underflow (Wrap or Wraparound)
Vulnerable versions: <= 1.0.0
Patched in: unpatched

Summary: Integer underflow in Frontier

Details:
### Impact

A bug in Frontier's MODEXP precompile implementation can cause an integer underflow in certain conditions. This will cause a node crash for debug builds. For release builds (and production WebAssembly binaries), the impact is limited as it can only cause a normal EVM out-of-gas. It is recommended that you apply the patch as soon as possible.

If you do not use MODEXP precompile in your runtime, then you are not impacted.

### Patches

Patches are applied in PR #549.

### Workarounds

None.

### References

Patch PR: #549

### Credits

Thanks to SR-Labs for discovering the security vulnerability, and thanks to PureStake team for the patches.

### For more information

If you have any questions or comments about this advisory:
* Open an issue in the [Frontier repo](https://github.com/paritytech/frontier)
GitHub Security Advisory: GHSA-mjvm-mhgc-q4gp
Package: fc-rpc (RUST)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-190: Integer Overflow or Wraparound
Vulnerable versions: <= 1.0.0
Patched in: unpatched

Summary: Incorrect parsing of EVM reversion exit reason in RPC

Details:
### Impact

A low severity security issue was discovered affecting parsing of the RPC result of the exit reason in case of EVM reversion. In release build, this would cause the exit reason being incorrectly parsed and returned by RPC. In debug build, this would cause an overflow panic.

No action is needed unless you have a bridge node that needs to distinguish different reversion exit reasons and you used RPC for this.

### Patches

The issue is patched in https://github.com/paritytech/frontier/pull/820

### Workarounds

None.

### References

PR https://github.com/paritytech/frontier/pull/820

### For more information

If you have any questions or comments about this advisory:
* Email [Wei Tang](mailto:wei@that.world)
GitHub Security Advisory: GHSA-fcmm-54jp-7vf6
Package: pallet-evm-precompile-modexp (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-682: Incorrect Calculation
Vulnerable versions: <= 1.0.0
Patched in: unpatched

Summary: Frontier's modexp precompile is slow for even modulus

Details:
### Impact

Frontier's `modexp` precompile uses `num-bigint` crate under the hood. [In the implementation](https://github.com/rust-num/num-bigint/blob/6f2b8e0fc218dbd0f49bebb8db2d1a771fe6bafa/src/biguint/power.rs#L134), the cases for modulus being even and modulus being odd are treated separately. Odd modulus uses the fast Montgomery multiplication, and even modulus uses the slow plain power algorithm. This gas cost discrepancy was not accounted for in the `modexp` precompile, leading to possible denial of service attacks.

### Patches

No fixes for `num-bigint` is currently available, and thus this advisory will be first fixed in the short term by raising the gas costs for even modulus, and in the long term fixing it in `num-bigint` or switching to another modexp implementation.

The short-term fix for Frontier is deployed at [PR 1017](https://github.com/paritytech/frontier/pull/1017).

The recommendations are as follows:

- If you anticipate malicious validators, it's recommended to issue an emergency runtime upgrade as soon as possible.
- If you do not anticipate malicious validators, it's recommended to issue a normal runtime upgrade, as Substrate has builtin timeout protection when validators are building blocks.

### Workarounds

None.

### References

A similar issue was presented in Geth's implementation and the fix can be found [here](https://go-review.googlesource.com/c/go/+/420897).
GitHub Security Advisory: GHSA-hw4v-5x4h-c3xm
Package: pallet-ethereum (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-20: Improper Input Validation, CWE-1284: Improper Validation of Specified Quantity in Input
Vulnerable versions: <= 3.0.0
Patched in: unpatched

Summary: Transaction validity oversight in pallet-ethereum

Details:
### Impact

A bug in `pallet-ethereum` can cause invalid transactions to be included in the Ethereum block state in `pallet-ethereum` due to not validating the input data size. Any invalid transactions included this way have no possibility to alter the internal Ethereum or Substrate state. The transaction will appear to have be included, but is of no effect as it is rejected by the EVM engine. The impact is further limited by Substrate extrinsic size constraints.

### Patches

Patches are applied in PR #465.

### Workarounds

None.

### References

Patch PR: https://github.com/paritytech/frontier/pull/465

### For more information

If you have any questions or comments about this advisory:
* Open an issue in the [Frontier repo](https://github.com/paritytech/frontier)
GitHub Security Advisory: GHSA-6jgw-rgmm-7cv6
Package: pyo3 (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-416: Use After Free
Vulnerable versions: >= 0.22.0, < 0.22.4
Patched in: 0.22.4

Summary:  PyO3 has a risk of use-after-free in `borrowed` reads from Python weak references

Details:
The family of functions to read "borrowed" values from Python weak references were fundamentally unsound, because the weak reference does itself not have ownership of the value. At any point the last strong reference could be cleared and the borrowed value would become dangling.

In PyO3 0.22.4 these functions have all been deprecated and patched to leak a strong reference as a mitigation. PyO3 0.23 will remove these functions entirely.
GitHub Security Advisory: GHSA-f8x4-f32r-w556
Package: pyo3 (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-416: Use After Free
Vulnerable versions: >= 0.22.0, < 0.22.4
Patched in: 0.22.4

Summary: Duplicate Advisory: PyO3 has a risk of use-after-free in `borrowed` reads from Python weak references

Details:
## Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-6jgw-rgmm-7cv6. This link is maintained to preserve external references.

## Original Advisory

The family of functions to read "borrowed" values from Python weak references were fundamentally unsound, because the weak reference does itself not have ownership of the value. At any point the last strong reference could be cleared and the borrowed value would become dangling.

In PyO3 0.22.4 these functions have all been deprecated and patched to leak a strong reference as a mitigation. PyO3 0.23 will remove these functions entirely.
GitHub Security Advisory: GHSA-pfr9-2p92-qrhq
Package: dbn (RUST)
Severity: MODERATE (CVSS 5.5)
CWE: CWE-126: Buffer Over-read
Vulnerable versions: < 0.22.0
Patched in: 0.22.0

Summary: Databento Binary Encoding (DBN) has a heap buffer overflow using c_chars_to_str function

Details:
The `heap-buffer-overflow` is triggered in the `strlen()` function when handling the `c_chars_to_str` function in the dbn crate. This vulnerability occurs because the `CStr::from_ptr()` function in Rust assumes that the provided C string is null-terminated. However, there is no guarantee that the input chars array passed to the c_chars_to_str function is properly null-terminated.

If the chars array does not contain a null byte (\0), strlen() will continue to read beyond the bounds of the buffer in search of a null terminator. This results in an out-of-bounds memory read and can lead to a heap-buffer-overflow, potentially causing memory corruption or exposing sensitive information.
GitHub Security Advisory: GHSA-qjrv-v6qp-x99x
Package: surrealdb-core (RUST)
Severity: HIGH (CVSS 6.5)
CWE: CWE-248: Uncaught Exception
Vulnerable versions: >= 2.0.0, < 2.0.4
Patched in: 2.0.4

Summary: SurrealDB has an Uncaught Exception Handling Parsing Errors on Empty Strings

Details:
The error rendering code from the parser would panic when handling failed parsing of queries where the error occurred when converting an empty string to a SurrealDB value. This would be the case when casting an empty string to a `record`, `duration` or `datetime`, as well as potentially when parsing an empty string to JSON or providing an empty string to the `type::field` and `type::fields` functions.

### Impact

A client that is authorized to run queries in a SurrealDB server would be able to execute a malformed query which would fail to parse when converting an empty string and cause a panic in the error rendering code. This would crash the server, leading to denial of service.

### Patches

- Version 2.0.4 and later are not affected by this issue.

### Workarounds

Affected users who are unable to update may want to limit the ability of untrusted clients to run arbitrary SurrealQL queries in the affected versions of SurrealDB. To limit the impact of the denial of service, SurrealDB administrators may also want to ensure that the SurrealDB process is running so that it can be automatically re-started after a crash.
GitHub Security Advisory: GHSA-qjrv-v6qp-x99x
Package: surrealdb (RUST)
Severity: HIGH (CVSS 6.5)
CWE: CWE-248: Uncaught Exception
Vulnerable versions: >= 2.0.0, < 2.0.4
Patched in: 2.0.4

Summary: SurrealDB has an Uncaught Exception Handling Parsing Errors on Empty Strings

Details:
The error rendering code from the parser would panic when handling failed parsing of queries where the error occurred when converting an empty string to a SurrealDB value. This would be the case when casting an empty string to a `record`, `duration` or `datetime`, as well as potentially when parsing an empty string to JSON or providing an empty string to the `type::field` and `type::fields` functions.

### Impact

A client that is authorized to run queries in a SurrealDB server would be able to execute a malformed query which would fail to parse when converting an empty string and cause a panic in the error rendering code. This would crash the server, leading to denial of service.

### Patches

- Version 2.0.4 and later are not affected by this issue.

### Workarounds

Affected users who are unable to update may want to limit the ability of untrusted clients to run arbitrary SurrealQL queries in the affected versions of SurrealDB. To limit the impact of the denial of service, SurrealDB administrators may also want to ensure that the SurrealDB process is running so that it can be automatically re-started after a crash.
GitHub Security Advisory: GHSA-5gc2-7c65-8fq8
Package: async-graphql (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 7.0.10
Patched in: 7.0.10

Summary: async-graphql Directive Overload

Details:
### Impact

- Service Disruption: The server may become unresponsive or extremely slow, potentially leading to downtime.
- Resource Exhaustion: Excessive use of server resources, such as CPU and memory, could negatively impact other services running on the same infrastructure.
- User Experience Degradation: Users may experience delays or failures when accessing the service, which could lead to frustration and loss of trust in the service.

### Patches

1. Upgrade to v7.0.10
2. Use [SchemaBuilder.limit_directives](https://docs.rs/async-graphql/latest/async_graphql/struct.SchemaBuilder.html#method.limit_directives) to limit the maximum number of directives for a single field.
GitHub Security Advisory: GHSA-vr8j-hgmm-jh9r
Package: openssl-src (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-667: Improper Locking
Vulnerable versions: >= 300.0.0, < 300.0.12
Patched in: 300.0.12

Summary: Denial of service by double-checked locking in openssl-src

Details:
If an X.509 certificate contains a malformed policy constraint and policy processing is enabled, then a write lock will be taken twice recursively. On some operating systems (most widely: Windows) this results in a denial of service when the affected process hangs. Policy processing being enabled on a publicly facing server is not considered to be a common setup. Policy processing is enabled by passing the `-policy' argument to the command line utilities or by calling either `X509_VERIFY_PARAM_add0_policy()' or `X509_VERIFY_PARAM_set1_policies()' functions.
GitHub Security Advisory: GHSA-r2jw-c95q-rj29
Package: cocoon (RUST)
Severity: MODERATE (CVSS 4.5)
CWE: CWE-323: Reusing a Nonce, Key Pair in Encryption
Vulnerable versions: < 0.4.0
Patched in: 0.4.0

Summary: Duplicate Advisory: cocoon Reuses a Nonce, Key Pair in Encryption

Details:
### Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-6878-6wc2-pf5h. This link is maintained to preserve external references.

### Original Description
Versions of the package cocoon before 0.4.0 are vulnerable to Reusing a Nonce, Key Pair in Encryption when the encrypt, wrap, and dump functions are sequentially called. An attacker can generate the same ciphertext by creating a new encrypted message with the same cocoon object.

**Note:**
The issue does NOT affect objects created with Cocoon::new which utilizes ThreadRng.
GitHub Security Advisory: GHSA-vrcx-gx3g-j3h8
Package: sqlite-vec (RUST)
Severity: HIGH (CVSS 9.1)
CWE: CWE-122: Heap-based Buffer Overflow, CWE-787: Out-of-bounds Write
Vulnerable versions: < 0.1.3
Patched in: 0.1.3

Summary: Heap-based Buffer Overflow in sqlite-vec

Details:
sqlite-vec v0.1.1 was discovered to contain a heap buffer overflow via the npy_token_next function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted file.
GitHub Security Advisory: GHSA-2wq5-g96f-mv3v
Package: ouch (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: < 0.3.1
Patched in: 0.3.1

Summary: Ouch! allows a segmentation fault due to use of uninitialized memory

Details:
When trying to decompress a file using "ouch", we can reach the function "ouch::archive::zip::convert_zip_date_time". In the function, there is a unsafe function, "transmute". Once the "transmute" function is called to convert the type of "month" object, the address of the object is changed to the uninitialized memory region. After that, when other function tries to dereference "month", segmentation fault occurs.
GitHub Security Advisory: GHSA-2326-pfpj-vx3h
Package: lexical-core (RUST)
Severity: LOW (CVSS 0.0)
Vulnerable versions: < 1.0.0
Patched in: 1.0.0

Summary: lexical-core has multiple soundness issues

Details:
`RUSTSEC-2024-0377` contains multiple soundness issues:

 1. [Bytes::read() allows creating instances of types with invalid bit patterns](https://github.com/Alexhuszagh/rust-lexical/issues/102)
 1. [BytesIter::read() advances iterators out of bounds](https://github.com/Alexhuszagh/rust-lexical/issues/101)
 1. [The `BytesIter` trait has safety invariants but is public and not marked `unsafe`](https://github.com/Alexhuszagh/rust-lexical/issues/104)
 1. [`write_float()` calls `MaybeUninit::assume_init()` on uninitialized data, which is is not allowed by the Rust abstract machine](https://github.com/Alexhuszagh/rust-lexical/issues/95)
 1. [`radix()` calls `MaybeUninit::assume_init()` on uninitialized data, which is is not allowed by the Rust abstract machine](https://github.com/Alexhuszagh/rust-lexical/issues/126)

Version 1.0 fixes these issues, removes the vast majority of `unsafe` code, and also fixes some correctness issues.
GitHub Security Advisory: GHSA-c2hm-mjxv-89r4
Package: lexical (RUST)
Severity: LOW (CVSS 0.0)
Vulnerable versions: <= 6.1.1
Patched in: 7.0.0

Summary: Multiple soundness issues in lexical

Details:
`lexical` contains multiple soundness issues:

 1. [Bytes::read() allows creating instances of types with invalid bit patterns](https://github.com/Alexhuszagh/rust-lexical/issues/102)
 1. [BytesIter::read() advances iterators out of bounds](https://github.com/Alexhuszagh/rust-lexical/issues/101)
 1. [The `BytesIter` trait has safety invariants but is public and not marked `unsafe`](https://github.com/Alexhuszagh/rust-lexical/issues/104)
 1. [`write_float()` calls `MaybeUninit::assume_init()` on uninitialized data, which is is not allowed by the Rust abstract machine](https://github.com/Alexhuszagh/rust-lexical/issues/95)
1. [`radix()` calls `MaybeUninit::assume_init()` on uninitialized data, which is is not allowed by the Rust abstract machine](https://github.com/Alexhuszagh/rust-lexical/issues/126)

The crate also has some correctness issues.

## Alternatives

For quickly parsing floating-point numbers third-party crates are no longer needed. A fast float parsing algorithm by the author of `lexical` has been [merged](https://github.com/rust-lang/rust/pull/86761) into libcore.

For quickly parsing integers, consider `atoi` and `btoi` crates (100% safe code). `atoi_radix10` provides even faster parsing, but only with `-C target-cpu=native`, and at the cost of some `unsafe`.

For formatting integers in a `#[no_std]` context consider the [`numtoa`](https://crates.io/crates/numtoa) crate.

For working with big numbers consider `num-bigint` and `num-traits`.