deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-84x2-2qv6-qg56
Package: ckb (RUST)
Severity: CRITICAL (CVSS 0.0)
Vulnerable versions: < 0.34.0
Patched in: 0.34.0

Summary: Nervos CKB P2P DoS Attacks

Details:
The P2P protocols lack of rate limit. For example, in relay protocol, when a node receives a broadcasted `tx_hashes`, it will mark it in memory to avoid duplicated requests. [code → ](https://github.com/nervosnetwork/ckb/blob/26e4837212c392c3c706a0da7a056131fb060433/sync/src/relayer/transactions_process.rs#L67).

It is easy to establish a DoS attach by generating random tx hashes.

### Impact

It affects all nodes connected to the P2P network.

### Workarounds

Apply rate limit on the data sent to CKB P2P port.
GitHub Security Advisory: GHSA-q669-2vfg-cxcg
Package: ckb (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: <= 0.31.0
Patched in: 0.31.1

Summary: Nervos CKB Unaligned Pointer Dereference

Details:
via bounty@nervos.org

There are multiple type conversions in ckb that unsafely cast between byte pointers and other types of pointers. This results in unaligned pointers, which are not allowed by the Rust language, and are considered undefined behavior, meaning that the compiler is free to do anything with code. This can lead to unpredictable bugs that can become security vulnerabilities.

Some of the bugs here could potentially lead to buffer overreads in malformed data (it's not clear to me as I haven't investigated the practical impact of these bugs).

Two of these (in blockchain.rs) do not create unaligned data. They do though perform an unsafe operation that may not uphold the invariants of the safe function they are in, and could lead to undefined behavior and buffer overreads on malformed input.

These are of the same nature as those in my previous report about the molecule crate.

Patch attached for commit 1b09e37c8e1b7945495cd18d9782417fbe51e986 that fixes all cases I know of at this time.

Please consider this report for reward under the terms of the bug bounty program.

Related advisory: https://github.com/nervosnetwork/molecule/security/advisories/GHSA-rffv-8x7x-p7pw
GitHub Security Advisory: GHSA-p75g-gcv5-42qg
Package: grin (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-345: Insufficient Verification of Data Authenticity
Vulnerable versions: >= 3.0.0, < 4.0.0
Patched in: 4.0.0

Summary: Grin insufficient data validation

Details:
Grin 3.0.0 before 4.0.0 has insufficient validation of data related to Mimblewimble.
GitHub Security Advisory: GHSA-6x52-88cq-55q5
Package: grin (RUST)
Severity: MODERATE (CVSS 5.3)
Vulnerable versions: < 3.1.0
Patched in: 3.1.0

Summary: Grin allows attackers to adversely affect availability of data on a Mimblewimble blockchain

Details:
Grin before 3.1.0 allows attackers to adversely affect availability of data on a Mimblewimble blockchain.
GitHub Security Advisory: GHSA-7w6p-rwhg-7h3g
Package: grin (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: < 3.0.0
Patched in: 3.0.0

Summary: Grin Insufficient Validation

Details:
Grin through 2.1.1 has Insufficient Validation.
GitHub Security Advisory: GHSA-h84q-m8rr-3v9q
Package: wasmtime (RUST)
Severity: LOW (CVSS 3.8)
CWE: CWE-787: Out-of-bounds Write
Vulnerable versions: < 1.0.2
Patched in: 1.0.2

Summary: wasmtime_trap_code C API function has out of bounds write vulnerability

Details:
### Impact

There is a bug in Wasmtime's C API implementation where the definition of the `wasmtime_trap_code` does not match its declared signature in the `wasmtime/trap.h` header file. This discrepancy causes the function implementation to perform a 4-byte write into a 1-byte buffer provided by the caller. This can lead to three zero bytes being written beyond the 1-byte location provided by the caller.

### Patches

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

### Workarounds

This can be worked around by providing a 4-byte buffer casted to a 1-byte buffer when calling `wasmtime_trap_code`. Users of the `wasmtime` crate are not affected by this issue, only users of the C API function `wasmtime_trap_code` are affected.

### References

* [Definition of `wasmtime_trap_code`](https://docs.wasmtime.dev/c-api/trap_8h.html#a6580f4f209d3eaebb6e8b9a901a30b7a)
* [Mailing list announcement](https://groups.google.com/a/bytecodealliance.org/g/sec-announce/c/c1HBDDJwNPA)
* [Patch to fix for `main` branch](https://github.com/bytecodealliance/wasmtime/commit/5b6d5e78de106503b3b9add218bb3d2b1d63c493)

### For more information

If you have any questions or comments about this advisory:

* Reach out to us on [the Bytecode Alliance Zulip chat](https://bytecodealliance.zulipchat.com/#narrow/stream/217126-wasmtime)
* Open an issue in [the bytecodealliance/wasmtime repository](https://github.com/bytecodealliance/wasmtime/)
GitHub Security Advisory: GHSA-h84q-m8rr-3v9q
Package: wasmtime (RUST)
Severity: LOW (CVSS 3.8)
CWE: CWE-787: Out-of-bounds Write
Vulnerable versions: >= 2.0.0, < 2.0.2
Patched in: 2.0.2

Summary: wasmtime_trap_code C API function has out of bounds write vulnerability

Details:
### Impact

There is a bug in Wasmtime's C API implementation where the definition of the `wasmtime_trap_code` does not match its declared signature in the `wasmtime/trap.h` header file. This discrepancy causes the function implementation to perform a 4-byte write into a 1-byte buffer provided by the caller. This can lead to three zero bytes being written beyond the 1-byte location provided by the caller.

### Patches

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

### Workarounds

This can be worked around by providing a 4-byte buffer casted to a 1-byte buffer when calling `wasmtime_trap_code`. Users of the `wasmtime` crate are not affected by this issue, only users of the C API function `wasmtime_trap_code` are affected.

### References

* [Definition of `wasmtime_trap_code`](https://docs.wasmtime.dev/c-api/trap_8h.html#a6580f4f209d3eaebb6e8b9a901a30b7a)
* [Mailing list announcement](https://groups.google.com/a/bytecodealliance.org/g/sec-announce/c/c1HBDDJwNPA)
* [Patch to fix for `main` branch](https://github.com/bytecodealliance/wasmtime/commit/5b6d5e78de106503b3b9add218bb3d2b1d63c493)

### For more information

If you have any questions or comments about this advisory:

* Reach out to us on [the Bytecode Alliance Zulip chat](https://bytecodealliance.zulipchat.com/#narrow/stream/217126-wasmtime)
* Open an issue in [the bytecodealliance/wasmtime repository](https://github.com/bytecodealliance/wasmtime/)
GitHub Security Advisory: GHSA-4jwq-572w-4388
Package: evm-core (RUST)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling, CWE-787: Out-of-bounds Write
Vulnerable versions: = 0.26.0
Patched in: 0.26.1

Summary: Memory over-allocation in evm crate

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

### Patches
The flaw was corrected in commit `19ade85`. Users should upgrade to `==0.21.1, ==0.23.1, ==0.24.1, ==0.25.1, >=0.26.1`.

### Workarounds
None. Please upgrade your `evm` crate version

### References
Fix commit: https://github.com/rust-blockchain/evm/commit/19ade858c430ab13eb562764a870ac9f8506f8dd

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [evm repo](https://github.com/rust-blockchain/evm)
* Email [Wei](mailto:wei@that.world)
GitHub Security Advisory: GHSA-4jwq-572w-4388
Package: evm-core (RUST)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling, CWE-787: Out-of-bounds Write
Vulnerable versions: = 0.25.0
Patched in: 0.25.1

Summary: Memory over-allocation in evm crate

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

### Patches
The flaw was corrected in commit `19ade85`. Users should upgrade to `==0.21.1, ==0.23.1, ==0.24.1, ==0.25.1, >=0.26.1`.

### Workarounds
None. Please upgrade your `evm` crate version

### References
Fix commit: https://github.com/rust-blockchain/evm/commit/19ade858c430ab13eb562764a870ac9f8506f8dd

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [evm repo](https://github.com/rust-blockchain/evm)
* Email [Wei](mailto:wei@that.world)
GitHub Security Advisory: GHSA-4jwq-572w-4388
Package: evm-core (RUST)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling, CWE-787: Out-of-bounds Write
Vulnerable versions: = 0.24.0
Patched in: 0.24.1

Summary: Memory over-allocation in evm crate

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

### Patches
The flaw was corrected in commit `19ade85`. Users should upgrade to `==0.21.1, ==0.23.1, ==0.24.1, ==0.25.1, >=0.26.1`.

### Workarounds
None. Please upgrade your `evm` crate version

### References
Fix commit: https://github.com/rust-blockchain/evm/commit/19ade858c430ab13eb562764a870ac9f8506f8dd

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [evm repo](https://github.com/rust-blockchain/evm)
* Email [Wei](mailto:wei@that.world)
GitHub Security Advisory: GHSA-4jwq-572w-4388
Package: evm-core (RUST)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling, CWE-787: Out-of-bounds Write
Vulnerable versions: = 0.23.0
Patched in: 0.23.1

Summary: Memory over-allocation in evm crate

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

### Patches
The flaw was corrected in commit `19ade85`. Users should upgrade to `==0.21.1, ==0.23.1, ==0.24.1, ==0.25.1, >=0.26.1`.

### Workarounds
None. Please upgrade your `evm` crate version

### References
Fix commit: https://github.com/rust-blockchain/evm/commit/19ade858c430ab13eb562764a870ac9f8506f8dd

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [evm repo](https://github.com/rust-blockchain/evm)
* Email [Wei](mailto:wei@that.world)
GitHub Security Advisory: GHSA-4jwq-572w-4388
Package: evm-core (RUST)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling, CWE-787: Out-of-bounds Write
Vulnerable versions: = 0.22.0
Patched in: 0.22.1

Summary: Memory over-allocation in evm crate

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

### Patches
The flaw was corrected in commit `19ade85`. Users should upgrade to `==0.21.1, ==0.23.1, ==0.24.1, ==0.25.1, >=0.26.1`.

### Workarounds
None. Please upgrade your `evm` crate version

### References
Fix commit: https://github.com/rust-blockchain/evm/commit/19ade858c430ab13eb562764a870ac9f8506f8dd

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [evm repo](https://github.com/rust-blockchain/evm)
* Email [Wei](mailto:wei@that.world)
GitHub Security Advisory: GHSA-4jwq-572w-4388
Package: evm (RUST)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling, CWE-787: Out-of-bounds Write
Vulnerable versions: = 0.26.0
Patched in: 0.26.1

Summary: Memory over-allocation in evm crate

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

### Patches
The flaw was corrected in commit `19ade85`. Users should upgrade to `==0.21.1, ==0.23.1, ==0.24.1, ==0.25.1, >=0.26.1`.

### Workarounds
None. Please upgrade your `evm` crate version

### References
Fix commit: https://github.com/rust-blockchain/evm/commit/19ade858c430ab13eb562764a870ac9f8506f8dd

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [evm repo](https://github.com/rust-blockchain/evm)
* Email [Wei](mailto:wei@that.world)
GitHub Security Advisory: GHSA-4jwq-572w-4388
Package: evm (RUST)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling, CWE-787: Out-of-bounds Write
Vulnerable versions: = 0.25.0
Patched in: 0.25.1

Summary: Memory over-allocation in evm crate

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

### Patches
The flaw was corrected in commit `19ade85`. Users should upgrade to `==0.21.1, ==0.23.1, ==0.24.1, ==0.25.1, >=0.26.1`.

### Workarounds
None. Please upgrade your `evm` crate version

### References
Fix commit: https://github.com/rust-blockchain/evm/commit/19ade858c430ab13eb562764a870ac9f8506f8dd

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [evm repo](https://github.com/rust-blockchain/evm)
* Email [Wei](mailto:wei@that.world)
GitHub Security Advisory: GHSA-4jwq-572w-4388
Package: evm (RUST)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling, CWE-787: Out-of-bounds Write
Vulnerable versions: = 0.24.0
Patched in: 0.24.1

Summary: Memory over-allocation in evm crate

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

### Patches
The flaw was corrected in commit `19ade85`. Users should upgrade to `==0.21.1, ==0.23.1, ==0.24.1, ==0.25.1, >=0.26.1`.

### Workarounds
None. Please upgrade your `evm` crate version

### References
Fix commit: https://github.com/rust-blockchain/evm/commit/19ade858c430ab13eb562764a870ac9f8506f8dd

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [evm repo](https://github.com/rust-blockchain/evm)
* Email [Wei](mailto:wei@that.world)
GitHub Security Advisory: GHSA-4jwq-572w-4388
Package: evm (RUST)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling, CWE-787: Out-of-bounds Write
Vulnerable versions: = 0.23.0
Patched in: 0.23.1

Summary: Memory over-allocation in evm crate

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

### Patches
The flaw was corrected in commit `19ade85`. Users should upgrade to `==0.21.1, ==0.23.1, ==0.24.1, ==0.25.1, >=0.26.1`.

### Workarounds
None. Please upgrade your `evm` crate version

### References
Fix commit: https://github.com/rust-blockchain/evm/commit/19ade858c430ab13eb562764a870ac9f8506f8dd

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [evm repo](https://github.com/rust-blockchain/evm)
* Email [Wei](mailto:wei@that.world)
GitHub Security Advisory: GHSA-4jwq-572w-4388
Package: evm (RUST)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling, CWE-787: Out-of-bounds Write
Vulnerable versions: = 0.22.0
Patched in: 0.22.1

Summary: Memory over-allocation in evm crate

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

### Patches
The flaw was corrected in commit `19ade85`. Users should upgrade to `==0.21.1, ==0.23.1, ==0.24.1, ==0.25.1, >=0.26.1`.

### Workarounds
None. Please upgrade your `evm` crate version

### References
Fix commit: https://github.com/rust-blockchain/evm/commit/19ade858c430ab13eb562764a870ac9f8506f8dd

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [evm repo](https://github.com/rust-blockchain/evm)
* Email [Wei](mailto:wei@that.world)
GitHub Security Advisory: GHSA-4jwq-572w-4388
Package: evm-core (RUST)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling, CWE-787: Out-of-bounds Write
Vulnerable versions: <= 0.21.0
Patched in: 0.21.1

Summary: Memory over-allocation in evm crate

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

### Patches
The flaw was corrected in commit `19ade85`. Users should upgrade to `==0.21.1, ==0.23.1, ==0.24.1, ==0.25.1, >=0.26.1`.

### Workarounds
None. Please upgrade your `evm` crate version

### References
Fix commit: https://github.com/rust-blockchain/evm/commit/19ade858c430ab13eb562764a870ac9f8506f8dd

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [evm repo](https://github.com/rust-blockchain/evm)
* Email [Wei](mailto:wei@that.world)
GitHub Security Advisory: GHSA-4jwq-572w-4388
Package: evm (RUST)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling, CWE-787: Out-of-bounds Write
Vulnerable versions: <= 0.21.0
Patched in: 0.21.1

Summary: Memory over-allocation in evm crate

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

### Patches
The flaw was corrected in commit `19ade85`. Users should upgrade to `==0.21.1, ==0.23.1, ==0.24.1, ==0.25.1, >=0.26.1`.

### Workarounds
None. Please upgrade your `evm` crate version

### References
Fix commit: https://github.com/rust-blockchain/evm/commit/19ade858c430ab13eb562764a870ac9f8506f8dd

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [evm repo](https://github.com/rust-blockchain/evm)
* Email [Wei](mailto:wei@that.world)
GitHub Security Advisory: GHSA-7g9j-g5jg-3vv3
Package: snow (RUST)
Severity: LOW (CVSS 3.1)
CWE: CWE-440: Expected Behavior Violation
Vulnerable versions: < 0.9.5
Patched in: 0.9.5

Summary: Unauthenticated Nonce Increment in snow

Details:
### Impact
There was a logic bug where unauthenticated payloads could still cause a nonce increment in snow's internal state. For an attacker with the ability to inject packets into the channel Noise is talking over, this allows a denial-of-service type attack which could prevent communication as it causes the sending and receiving side to be expecting different nonce values than would arrive.

Note that this only affects those who are using the stateful `TransportState`, not those using `StatelessTransportState`.

### Patches
This has been patched in version 0.9.5, and all users are recommended to update.

### References
There will be a more formal report of this in the near future.
GitHub Security Advisory: GHSA-9f9p-cp3c-72jf
Package: trillium-client (RUST)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting'), CWE-436: Interpretation Conflict
Vulnerable versions: < 0.5.4
Patched in: 0.5.4

Summary: Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting') in trillium-http and trillium-client

Details:
### Summary
Insufficient validation of outbound header values may lead to request splitting or response splitting attacks in scenarios where attackers have sufficient control over outbound headers.

### Details
Outbound `trillium_http::HeaderValue` and `trillium_http::HeaderName` can be constructed infallibly and were not checked for illegal bytes when sending requests from the client or responses from the server. Thus, if an attacker has sufficient control over header values (or names) in a request or response that they could inject `\r\n` sequences, they could get the client and server out of sync, and then pivot to gain control over other parts of requests or responses. (i.e. exfiltrating data from other requests, SSRF, etc.)

### Patches

#### trillium-http >= 0.3.12:
* If a header name is invalid in server response headers, the specific header and any associated values are omitted from network transmission.
* If a header value is invalid in server response headers, the individual header value is omitted from network transmission. Other headers values with the same header name will still be sent.

#### trillium-client >= 0.5.4:
* If any header name or header value is invalid in the client request headers, awaiting the client Conn returns an `Error::MalformedHeader` prior to any network access.

### Workarounds

trillium services and client applications should sanitize or validate untrusted input that is included in header values and header names. Carriage return, newline, and null characters are not allowed.

### Impact

This only affects use cases where attackers have control of outbound headers, and can insert "\r\n" sequences. Specifically, if untrusted and unvalidated input is inserted into header names or values.

### A note on timing from @jbr on behalf of `trillium-rs`

@divergentdave filed this vulnerability many months ago but I did not see it until the evening of Jan 23, 2024. Patches were issued less than 24h after reading the vulnerability. The [security policy](https://github.com/trillium-rs/trillium/blob/main/SECURITY.md) has been [updated](https://github.com/trillium-rs/trillium/commit/b27950ceae52aa7a0f482494fe67b6069234d417) to avoid delays like this in the future.