deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-v83q-83hj-rw38
Package: ntpd (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-369: Divide By Zero, CWE-703: Improper Check or Handling of Exceptional Conditions
Vulnerable versions: < 1.5.0
Patched in: 1.5.0

Summary: ntpd NTS client denial of service via wrongly sized cookies

Details:
Two denial of service vulnerabilities were found in ntpd-rs related to the handling of NTS cookies in our client functionality. Whenever an NTS source is configured and the server behind that source is sending zero-sized cookies or cookies larger than what would fit in our buffer size, ntpd-rs would crash. Only configured NTS sources can abuse these vulnerabilities. NTP sources or third parties that are not configured cannot make use of these vulnerabilities.

For zero-sized cookies: a division by zero would force an exit when the number of new cookies that would need to be requested is calculated. In ntpd-rs 1.5.0 a check was added to prevent the division by zero.

For large cookies: while trying to send a NTP request with the cookie included, the buffer is too small to handle the cookie and an exit of ntpd-rs is forced once a write to the buffer is attempted. The memory outside the buffer would not be written to in this case. In ntpd-rs 1.5.0 a check was added that prevents accepting cookies larger than 350 bytes.

Users of older versions of ntpd-rs are recommended to update to the latest version. If an update is impossible, it is recommended to only add NTS sources to ntpd-rs that are trusted to not abuse this bug.
GitHub Security Advisory: GHSA-5pmw-9j92-3c4c
Package: openh264-sys2 (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-122: Heap-based Buffer Overflow, CWE-1395: Dependency on Vulnerable Third-Party Component
Vulnerable versions: < 0.8.0
Patched in: 0.8.0

Summary: OpenH264 Rust API Openh264 Decoding Functions Heap Overflow Vulnerability

Details:
OpenH264 recently reported a [heap overflow](https://github.com/cisco/openh264/security/advisories/GHSA-m99q-5j7x-7m9x) that was fixed in upstream [63db555](https://github.com/cisco/openh264/commit/63db555e30986e3a5f07871368dc90ae78c27449) and [integrated into](https://github.com/ralfbiedert/openh264-rs/commit/3a822fff0b4c9a984622ca2b179fe8898ac54b14) our 0.6.6 release. For users relying on Cisco's pre-compiled DLL, we also published 0.8.0, which is compatible with their latest fixed DLL version  2.6.0. 

In other words:
- if you rely on our `source` feature only, >=0.6.6 should be safe,
- if you rely on `libloading`, you must upgrade to 0.8.0 _and_ use their latest DLL >=2.6.0. 

Users handling untrusted video files should update immediately.
GitHub Security Advisory: GHSA-f8qm-hmm3-fv7f
Package: namada-apps (RUST)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: = 1.0.0
Patched in: 1.1.0

Summary: Namada-apps allows Excessive Computation in Mempool Validation

Details:
### Impact

A malicious transaction may cause an expensive computation in mempool validation.

A transaction with multiple repeated sections causes the section hash calculation used for signature validation to grow exponentially (and potentially even cubic) in proportion to number of sections. This may be used to significantly slow down operation of nodes.

### Patches

This issue has been patched in apps version 1.1.0. The transaction sections are now being checked for uniqueness and the number of permitted sections contained in a single transaction has been limited to 10,000.

### Workarounds

There are no workarounds and users are advised to upgrade.
GitHub Security Advisory: GHSA-82vg-5v4f-f9wq
Package: namada-apps (RUST)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: = 1.0.0
Patched in: 1.1.0

Summary: Namada-apps can Crash with Excessive Computation in Mempool Validation

Details:
### Impact

A malicious transaction may cause a crash in mempool validation.

A transaction with authorization section containing 256 public keys or more with valid matching signatures triggers an integer overflow in signature verification that causes a the node to panic.

### Patches

This issue has been patched in apps version 1.1.0. The mempool validation has been fixed to avoid overflow.

### Workarounds

There are no workarounds and users are advised to upgrade.
GitHub Security Advisory: GHSA-2gw2-qgjg-xh6p
Package: namada-apps (RUST)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-248: Uncaught Exception
Vulnerable versions: = 1.0.0
Patched in: 1.1.0

Summary: Namada-apps allows Post-Genesis Validator Bypass

Details:
### Impact

Ledger crash. A user is able to initialize a post-genesis validator with a negative commission rate using the `--force` flag. If this validator gets into the consensus set, then when computing PoS inflation inside `fn update_rewards_products_and_mint_inflation`, an instance of `mul_floor` will cause the return of an `Err`, which causes `finalize_block` to error.

### Patches

This issue has been patched in apps version 1.1.0. The PoS validity predicate now enforces that the commission rate is not negative and any transaction that fails the check will be rejected, both for newly initialized validators and for commission rate change of an existing validator.

### Workarounds

There are no workarounds and users are advised to upgrade.
GitHub Security Advisory: GHSA-h7h7-6mx3-r89v
Package: fyrox-core (RUST)
Severity: LOW (CVSS 0.0)
Vulnerable versions: >= 0.28.1, < 0.36
Patched in: 0.36

Summary: Fyrox has unsound usages of `Vec::from_raw_parts` 

Details:
The library provides a public safe API `transmute_vec_as_bytes`, which incorrectly assumes that any generic type `T` could have stable layout, causing to uninitialized memory exposure if the users pass any types with padding bytes as `T` and cast it to `u8` pointer.  

In the [issue](https://github.com/FyroxEngine/Fyrox/issues/630), we develop a PoC to show passing struct type to `transmute_vec_as_bytes` could lead to undefined behavior with `Vec::from_raw_parts`.  

The developers provide a patch by changing trait of `Copy` to `Pod`, which can make sure `T` should be plain data. This was patched in the latest version of [master](https://github.com/FyroxEngine/Fyrox/blob/3f9ad6f9667047dac051b0e97d544e5b38e5ae72/fyrox-core/src/lib.rs#L351-L360) branch, but still not on the latest release (0.28.1).
GitHub Security Advisory: GHSA-5v93-9mqw-p9mh
Package: orml-rewards (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-248: Uncaught Exception
Vulnerable versions: < 1.2.1
Patched in: 1.2.1

Summary: Uncaught Panic in ORML Rewards Pallet

Details:
## Summary
A vulnerability in the `add_share` function of the **Rewards** pallet (part of the ORML repository) can lead to an uncaught Rust panic when handling user-provided input exceeding the `u128` range.

## Affected Components
- **ORML Rewards** pallet (`rewards/src/lib.rs`)
- Any Substrate-based chain using ORML Rewards with `add_share` accepting unvalidated large `u128` inputs

## Technical Details
- `add_share` performs arithmetic on user-supplied values (`add_amount`) of type `T::Share` (mapped to `u128` in Acala).
- If `add_amount` is large enough (e.g., `i128::MAX`), the intermediate result may overflow and panic on the cast to `u128`.
- Validation occurs only after arithmetic, enabling a crafted input to trigger an overflow.

## Impact
A malicious user submitting a specially crafted extrinsic can cause a panic in the runtime:
- **Denial of Service** by crashing the node process.
- **Potential for invalid blocks** produced by validators.

## Likelihood
This issue is exploitable in production if there exists at least one rewards pool where reward tokens exceed twice the collateral tokens, allowing sufficiently large multiplication to exceed `u128` bounds.

## Remediation
- This issue is fixed in https://github.com/open-web3-stack/open-runtime-module-library/pull/1016

## Backport

The patch have been backported to following release branches:
- polkadot-stable2407
- polkadot-stable2409

A 1.0.1 patch release is made with this fix.
GitHub Security Advisory: GHSA-v7pc-74h8-xq2h
Package: hickory-proto (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-345: Insufficient Verification of Data Authenticity
Vulnerable versions: >= 0.25.0-alpha.1, < 0.25.0-alpha.5
Patched in: 0.25.0-alpha.5

Summary: Hickory DNS failure to verify self-signed RRSIG for DNSKEYs

Details:
Summary

The DNSSEC validation routines treat entire RRsets of DNSKEY records as trusted once they have established trust in only one of the DNSKEYs. As a result, if a zone includes a DNSKEY with a public key that matches a configured trust anchor, all keys in that zone will be trusted to authenticate other records in the zone. There is a second variant of this vulnerability involving DS records, where an authenticated DS record covering one DNSKEY leads to trust in signatures made by an unrelated DNSKEY in the same zone.

Details

verify_dnskey_rrset() will return Ok(true) if any record's public key matches a trust anchor. This results in verify_rrset() returning a Secure proof. This ultimately results in successfully verifying a response containing DNSKEY records. verify_default_rrset() looks up DNSKEY records by calling handle.lookup(), which takes the above code path. There's a comment following this that says "DNSKEYs were already validated by the inner query in the above lookup", but this is not the case. To fully verify the whole RRset of DNSKEYs, it would be necessary to check self-signatures by the trusted key over the other keys. Later in verify_default_rrset(), verify_rrset_with_dnskey() is called multiple times with different keys and signatures, and if any call succeeds, then its Proof is returned.

Similarly, verify_dnskey_rrset() returns Ok(false) if any DNSKEY record is covered by a DS record. A comment says "If all the keys are valid, then we are secure", but this is only checking that one key is authenticated by a DS in the parent zone's delegation point. This time, after control flow returns to verify_rrset(), it will call verify_default_rrset(). The special handling for DNSKEYs in verify_default_rrset() will then call verify_rrset_with_dnskey() using each KSK DNSKEY record, and if one call succeeds, return its Proof. If there are multiple KSK DNSKEYs in the RRset, then this leads to another authentication break. We need to either pass the authenticated DNSKEYs from the DS covering check to the RRSIG validation, or we need to perform this RRSIG validation of the DNSKEY RRset inside verify_dnskey_rrset() and cut verify_default_rrset() out of DNSKEY RRset validation entirely.
GitHub Security Advisory: GHSA-v7pc-74h8-xq2h
Package: hickory-proto (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-345: Insufficient Verification of Data Authenticity
Vulnerable versions: >= 0.8.0, < 0.24.3
Patched in: 0.24.3

Summary: Hickory DNS failure to verify self-signed RRSIG for DNSKEYs

Details:
Summary

The DNSSEC validation routines treat entire RRsets of DNSKEY records as trusted once they have established trust in only one of the DNSKEYs. As a result, if a zone includes a DNSKEY with a public key that matches a configured trust anchor, all keys in that zone will be trusted to authenticate other records in the zone. There is a second variant of this vulnerability involving DS records, where an authenticated DS record covering one DNSKEY leads to trust in signatures made by an unrelated DNSKEY in the same zone.

Details

verify_dnskey_rrset() will return Ok(true) if any record's public key matches a trust anchor. This results in verify_rrset() returning a Secure proof. This ultimately results in successfully verifying a response containing DNSKEY records. verify_default_rrset() looks up DNSKEY records by calling handle.lookup(), which takes the above code path. There's a comment following this that says "DNSKEYs were already validated by the inner query in the above lookup", but this is not the case. To fully verify the whole RRset of DNSKEYs, it would be necessary to check self-signatures by the trusted key over the other keys. Later in verify_default_rrset(), verify_rrset_with_dnskey() is called multiple times with different keys and signatures, and if any call succeeds, then its Proof is returned.

Similarly, verify_dnskey_rrset() returns Ok(false) if any DNSKEY record is covered by a DS record. A comment says "If all the keys are valid, then we are secure", but this is only checking that one key is authenticated by a DS in the parent zone's delegation point. This time, after control flow returns to verify_rrset(), it will call verify_default_rrset(). The special handling for DNSKEYs in verify_default_rrset() will then call verify_rrset_with_dnskey() using each KSK DNSKEY record, and if one call succeeds, return its Proof. If there are multiple KSK DNSKEYs in the RRset, then this leads to another authentication break. We need to either pass the authenticated DNSKEYs from the DS covering check to the RRSIG validation, or we need to perform this RRSIG validation of the DNSKEY RRset inside verify_dnskey_rrset() and cut verify_default_rrset() out of DNSKEY RRset validation entirely.
GitHub Security Advisory: GHSA-qm2p-4w45-v2vr
Package: grcov (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-787: Out-of-bounds Write
Vulnerable versions: < 0.8.20
Patched in: 0.8.20

Summary: grcov has an out of bounds write triggered by crafted coverage data

Details:
Function `grcov::covdir::get_coverage` uses the `unsafe` function `get_unchecked_mut` without validating that the index is in bounds.

This results in memory corruption, and could potentially allow arbitrary code execution provided that an attacker can feed the tool crafted coverage data.
GitHub Security Advisory: GHSA-37wc-h8xc-5hc4
Package: hickory-proto (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-345: Insufficient Verification of Data Authenticity
Vulnerable versions: >= 0.8.0, < 0.24.3
Patched in: 0.24.3

Summary: Hickory DNS's DNSSEC validation may accept broken authentication chains

Details:
### Summary
The DNSSEC validation routines treat entire RRsets of DNSKEY records as trusted once they have established trust in only one of the DNSKEYs. As a result, if a zone includes a DNSKEY with a public key that matches a configured trust anchor, all keys in that zone will be trusted to authenticate other records in the zone. There is a second variant of this vulnerability involving DS records, where an authenticated DS record covering one DNSKEY leads to trust in signatures made by an unrelated DNSKEY in the same zone.

### Details
`verify_dnskey_rrset()` will return `Ok(true)` if any record's public key matches a trust anchor. This results in `verify_rrset()` returning a `Secure` proof. This ultimately results in successfully verifying a response containing DNSKEY records. `verify_default_rrset()` looks up DNSKEY records by calling `handle.lookup()`, which takes the above code path. There's a comment following this that says "DNSKEYs were already validated by the inner query in the above lookup", but this is not the case. To fully verify the whole RRset of DNSKEYs, it would be necessary to check self-signatures by the trusted key over the other keys. Later in `verify_default_rrset()`, `verify_rrset_with_dnskey()` is called multiple times with different keys and signatures, and if any call succeeds, then its `Proof` is returned.

Similarly, `verify_dnskey_rrset()` returns `Ok(false)` if any DNSKEY record is covered by a DS record. A comment says "If all the keys are valid, then we are secure", but this is only checking that one key is authenticated by a DS in the parent zone's delegation point. This time, after control flow returns to `verify_rrset()`, it will call `verify_default_rrset()`. The special handling for DNSKEYs in `verify_default_rrset()` will then call `verify_rrset_with_dnskey()` using each KSK DNSKEY record, and if one call succeeds, return its `Proof`. If there are multiple KSK DNSKEYs in the RRset, then this leads to another authentication break. We need to either pass the authenticated DNSKEYs from the DS covering check to the RRSIG validation, or we need to perform this RRSIG validation of the DNSKEY RRset inside `verify_dnskey_rrset()` and cut `verify_default_rrset()` out of DNSKEY RRset validation entirely.

### PoC
The proof of concepts have been integrated into the conformance test suite, as `resolver::dnssec::scenarios::bogus::bogus_zone_plus_trust_anchor_dnskey` and `resolver::dnssec::scenarios::bogus::bogus_zone_plus_ds_covered_dnskey`.

### Impact
This impacts Hickory DNS users relying on DNSSEC verification in the client library, stub resolver, or recursive resolver.
GitHub Security Advisory: GHSA-mx2j-7cmv-353c
Package: cosmwasm-vm (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: < 1.5.10
Patched in: 1.5.10

Summary: wasmvm: Malicious smart contract can slow down block production

Details:
# CWA-2025-002

**Severity**

Medium (Moderate + Likely)[^1]

**Affected versions:**

- wasmvm >= 2.2.0, < 2.2.2
- wasmvm >= 2.1.0, < 2.1.5
- wasmvm >= 2.0.0, < 2.0.6
- wasmvm < 1.5.8

**Patched versions:**

- wasmvm 1.5.8, 2.0.6, 2.1.5, 2.2.2

## Description of the bug

The vulnerability can be used to slow down block production. The attack requires a malicious contract,
so permissioned chains are unlikely to be affected.

(We'll add more detail once chains had a chance to upgrade.)

## Patch

- 1.5: https://github.com/CosmWasm/cosmwasm/commit/2b7f2faa57a1efc8207455c37f87f1eee6035a27
- 2.0: https://github.com/CosmWasm/cosmwasm/commit/d6143b0aff16a39bbea4be37597d8e9d9b213d3b
- 2.1: https://github.com/CosmWasm/cosmwasm/commit/f0c04c03cbe2557634c1bbcdc2ce203fe7caca58
- 2.2: https://github.com/CosmWasm/cosmwasm/commit/a5d62f65b5eb947ebe40e2085b1c48a9d0a244d0

## Applying the patch

The patch will be shipped in releases of wasmvm. You can update more or less as follows:

1. Check the current wasmvm version: `go list -m github.com/CosmWasm/wasmvm`
2. Bump the `github.com/CosmWasm/wasmvm` dependency in your go.mod to one of the patched version
   depending on which minor version you are on; `go mod tidy`; commit.
3. If you use the static libraries `libwasmvm_muslc.aarch64.a`/`libwasmvm_muslc.x86_64.a`, update them accordingly.
4. Check the updated wasmvm version: `go list -m github.com/CosmWasm/wasmvm` and ensure you see 1.5.8, 2.0.6, 2.1.5 or 2.2.2.
5. Follow your regular practices to deploy chain upgrades.

The patch is consensus breaking and requires a coordinated upgrade.

## Acknowledgement

This issue was found by meadow101 who reported it to the Cosmos Bug Bounty Program on HackerOne.

If you believe you have found a bug in the Interchain Stack or would like to contribute to the
program by reporting a bug, please see <https://hackerone.com/cosmos>.

## Timeline

- 2024-11-24: Confio receives a report through the Cosmos bug bounty program maintained by Amulet.
- 2024-12-20: Confio security contributors confirm the report.
- 2024-01-27: Confio developed the patch internally.
- 2025-02-04: Patch gets released.

[^1]: following Amulet's Severity Classification Framework ACMv1.2: https://github.com/interchainio/security/blob/0295254e8645301ccb606d46108a45cede0a73e0/resources/CLASSIFICATION_MATRIX.md
GitHub Security Advisory: GHSA-mx2j-7cmv-353c
Package: cosmwasm-vm (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 2.0.0, < 2.0.9
Patched in: 2.0.9

Summary: wasmvm: Malicious smart contract can slow down block production

Details:
# CWA-2025-002

**Severity**

Medium (Moderate + Likely)[^1]

**Affected versions:**

- wasmvm >= 2.2.0, < 2.2.2
- wasmvm >= 2.1.0, < 2.1.5
- wasmvm >= 2.0.0, < 2.0.6
- wasmvm < 1.5.8

**Patched versions:**

- wasmvm 1.5.8, 2.0.6, 2.1.5, 2.2.2

## Description of the bug

The vulnerability can be used to slow down block production. The attack requires a malicious contract,
so permissioned chains are unlikely to be affected.

(We'll add more detail once chains had a chance to upgrade.)

## Patch

- 1.5: https://github.com/CosmWasm/cosmwasm/commit/2b7f2faa57a1efc8207455c37f87f1eee6035a27
- 2.0: https://github.com/CosmWasm/cosmwasm/commit/d6143b0aff16a39bbea4be37597d8e9d9b213d3b
- 2.1: https://github.com/CosmWasm/cosmwasm/commit/f0c04c03cbe2557634c1bbcdc2ce203fe7caca58
- 2.2: https://github.com/CosmWasm/cosmwasm/commit/a5d62f65b5eb947ebe40e2085b1c48a9d0a244d0

## Applying the patch

The patch will be shipped in releases of wasmvm. You can update more or less as follows:

1. Check the current wasmvm version: `go list -m github.com/CosmWasm/wasmvm`
2. Bump the `github.com/CosmWasm/wasmvm` dependency in your go.mod to one of the patched version
   depending on which minor version you are on; `go mod tidy`; commit.
3. If you use the static libraries `libwasmvm_muslc.aarch64.a`/`libwasmvm_muslc.x86_64.a`, update them accordingly.
4. Check the updated wasmvm version: `go list -m github.com/CosmWasm/wasmvm` and ensure you see 1.5.8, 2.0.6, 2.1.5 or 2.2.2.
5. Follow your regular practices to deploy chain upgrades.

The patch is consensus breaking and requires a coordinated upgrade.

## Acknowledgement

This issue was found by meadow101 who reported it to the Cosmos Bug Bounty Program on HackerOne.

If you believe you have found a bug in the Interchain Stack or would like to contribute to the
program by reporting a bug, please see <https://hackerone.com/cosmos>.

## Timeline

- 2024-11-24: Confio receives a report through the Cosmos bug bounty program maintained by Amulet.
- 2024-12-20: Confio security contributors confirm the report.
- 2024-01-27: Confio developed the patch internally.
- 2025-02-04: Patch gets released.

[^1]: following Amulet's Severity Classification Framework ACMv1.2: https://github.com/interchainio/security/blob/0295254e8645301ccb606d46108a45cede0a73e0/resources/CLASSIFICATION_MATRIX.md