deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-6698-mhxx-r84g
Package: ursa (RUST)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-327: Use of a Broken or Risky Cryptographic Algorithm
Vulnerable versions: <= 0.3.7
Patched in: unpatched

Summary: Ursa CL-Signatures Revocation allows verifiers to generate unique identifiers for holders

Details:
### Summary

The revocation scheme that is part of the Ursa CL-Signatures implementations has a flaw that could impact the privacy guarantees defined by the AnonCreds verifiable credential model. Notably, a malicious verifier may be able to generate a unique identifier for a holder providing a verifiable presentation that includes a Non-Revocation proof.

### Details

The revocation scheme that is part of the Ursa CL-Signatures implementations has a flaw that could impact the privacy guarantees defined by the AnonCreds verifiable credential model, potentially allowing a malicious verifier to generate a unique identifier for a holder that provides a verifiable presentation that includes a Non-Revocation proof.

The flaws affects all CL-Signature versions published from the [Hyperledger Ursa] repository to the [Ursa Rust Crate], and is fixed in all versions published from the [Hyperledger AnonCreds CL-Signatures] repository to the [AnonCreds CL-Signatures Rust Crate].

The addressing the flaw requires updating AnonCreds holder software (such as mobile wallets) to a corrected CL-Signature implementation, such as the [AnonCreds CL Signatures Rust Crate]. Verifying presentations from corrected holders requires a updating the verifier software to a corrected CL-Signatures implementation. An updated verifier based on AnonCreds CL-Signatures can verify presentations from holders built on either the flawed Ursa CL-Signature implementation or a corrected CL-Signature implementation

[Hyperledger Ursa]: https://github.com/hyperledger-archives/ursa
[Ursa Rust Crate]: https://crates.io/crates/ursa
[Hyperledger AnonCreds CL-Signatures]: https://github.com/hyperledger/anoncreds-clsignatures-rs
[AnonCreds CL-Signatures Rust Crate]: https://crates.io/crates/anoncreds-clsignatures

The flaw occurs as a result of generating a verifiable presentation that includes a Non-Revocation proof from a flawed implementation.

### Impact
The impact of the flaw is that a malicious verifier may be able to determine a unique identifier for a holder presenting a Non-Revocation proof.

### Mitigation

Upgrade libraries/holder applications that generate AnonCreds verifiable presentations using the [Ursa Rust Crate] to any version of the [AnonCreds CL-Signatures Rust Crate].
GitHub Security Advisory: GHSA-2q6j-gqc4-4gw3
Package: ursa (RUST)
Severity: LOW (CVSS 3.3)
CWE: CWE-829: Inclusion of Functionality from Untrusted Control Sphere
Vulnerable versions: <= 0.3.7
Patched in: unpatched

Summary: Breaking unlinkability in Identity Mixer using malicious keys

Details:
# CL Signatures Issuer Key Correctness Proof lacks of prime strength checking

A weakness in the Hyperledger AnonCreds specification that is not mitigated in the Ursa and AnonCreds implementations is that the Issuer does not publish a key correctness proof demonstrating that a generated private key is sufficient to meet the unlinkability guarantees of AnonCreds. A sufficient private key is one in which it's components `p` and `q` are safe primes, such that:

- `p` and `q` are both prime numbers
- `p` and `q` are not equal
- `p` and `q` have the same, sufficiently large, size
  - For example, using two values both 1024 bits long is sufficient, whereas using one value 2040 bits long and the other 8 bits long is not.

The Ursa and AnonCreds CL-Signatures implementations always generate a sufficient private key. A malicious issuer could in theory create a custom CL Signature implementation (derived from the Ursa or AnonCreds CL-Signatures implementations) that uses weakened private keys such that presentations from holders could be shared by verifiers  to the issuer who could determine the holder to which the credential was issued.

### Impact

This vulnerability could impact holders of AnonCreds credentials implemented using the CL-signature scheme in the Ursa and AnonCreds implementations of CL Signatures.

### Mitigations

[Jan Camenisch and Markus Michels. Proving in zero-knowledge that a number is the product of two safe primes] (pages 12-13) demonstrates a key correctness proof that could be used to show the issuer has generated a sufficiently strong private key, proving the characteristics listed above.

In a future version of AnonCreds, the additional key correctness proof could be published separately or added to the Credential Definition. In the meantime, Issuers in existing ecosystems can share such a proof with their ecosystem co-participants in an ad hoc manner.

[Jan Camenisch and Markus Michels. Proving in zero-knowledge that a number is the product of two safe primes]: https://www.brics.dk/RS/98/29/BRICS-RS-98-29.pdf

The lack of such a published key correctness proof allows a malicious Issuer to deliberately generate a private key that lacks the requirements listed above, enabling the Issuer to perform a brute force attack on presentations provided to colluding verifiers that breaks the unlinkability guarantee of AnonCreds.
GitHub Security Advisory: GHSA-2q6j-gqc4-4gw3
Package: anoncreds-clsignatures (RUST)
Severity: LOW (CVSS 3.3)
CWE: CWE-829: Inclusion of Functionality from Untrusted Control Sphere
Vulnerable versions: < 0.3
Patched in: unpatched

Summary: Breaking unlinkability in Identity Mixer using malicious keys

Details:
# CL Signatures Issuer Key Correctness Proof lacks of prime strength checking

A weakness in the Hyperledger AnonCreds specification that is not mitigated in the Ursa and AnonCreds implementations is that the Issuer does not publish a key correctness proof demonstrating that a generated private key is sufficient to meet the unlinkability guarantees of AnonCreds. A sufficient private key is one in which it's components `p` and `q` are safe primes, such that:

- `p` and `q` are both prime numbers
- `p` and `q` are not equal
- `p` and `q` have the same, sufficiently large, size
  - For example, using two values both 1024 bits long is sufficient, whereas using one value 2040 bits long and the other 8 bits long is not.

The Ursa and AnonCreds CL-Signatures implementations always generate a sufficient private key. A malicious issuer could in theory create a custom CL Signature implementation (derived from the Ursa or AnonCreds CL-Signatures implementations) that uses weakened private keys such that presentations from holders could be shared by verifiers  to the issuer who could determine the holder to which the credential was issued.

### Impact

This vulnerability could impact holders of AnonCreds credentials implemented using the CL-signature scheme in the Ursa and AnonCreds implementations of CL Signatures.

### Mitigations

[Jan Camenisch and Markus Michels. Proving in zero-knowledge that a number is the product of two safe primes] (pages 12-13) demonstrates a key correctness proof that could be used to show the issuer has generated a sufficiently strong private key, proving the characteristics listed above.

In a future version of AnonCreds, the additional key correctness proof could be published separately or added to the Credential Definition. In the meantime, Issuers in existing ecosystems can share such a proof with their ecosystem co-participants in an ad hoc manner.

[Jan Camenisch and Markus Michels. Proving in zero-knowledge that a number is the product of two safe primes]: https://www.brics.dk/RS/98/29/BRICS-RS-98-29.pdf

The lack of such a published key correctness proof allows a malicious Issuer to deliberately generate a private key that lacks the requirements listed above, enabling the Issuer to perform a brute force attack on presentations provided to colluding verifiers that breaks the unlinkability guarantee of AnonCreds.
GitHub Security Advisory: GHSA-27wg-99g8-2v4v
Package: evm (RUST)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-703: Improper Check or Handling of Exceptional Conditions
Vulnerable versions: <= 0.41.0
Patched in: 0.41.1

Summary: Rust EVM erroneousle handles `record_external_operation` error return

Details:
### Impact

In `rust-evm`, a feature called `record_external_operation` was introduced, allowing library users to record custom gas changes. This feature can have some bogus interactions with the call stack.

In particular, during finalization of a `CREATE` or `CREATE2`, in the case that [the substack execution happens successfully](https://github.com/rust-ethereum/evm/blob/release-v041/src/executor/stack/executor.rs#L1012C25-L1012C69), `rust-evm` will first commit the substate, and then call `record_external_operation(Write(out_code.len()))`. If `record_external_operation` later fails, this error is returned to the parent call stack, instead of `Succeeded`. Yet, the substate commitment already happened. This causes smart contracts able to commit state changes, when the parent caller contract receives zero address (which usually indicates that the execution has failed).

This issue only impacts library users with custom `record_external_operation` that returns errors.

### Patches

The issue is patched in release 0.41.1. The commit can be seem [here](https://github.com/rust-ethereum/evm/commit/d8991ec727ad0fb64fe9957a3cd307387a6701e4).

### Workarounds

None.

### References

Patch PR [#264](https://github.com/rust-ethereum/evm/pull/264).
GitHub Security Advisory: GHSA-p4v8-jgcv-9g75
Package: safe_pqc_kyber (RUST)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: < 0.6.2
Patched in: 0.6.2

Summary: safe_pqc_kyber leaks parts of secret keys

Details:
### Impact
On some platforms, when an attacker can time decapsulation, and in particular when the attacker can forge cipher texts, they can learn (parts of) the secret key.

Does not apply to ephemeral usage, such as when used in the regular way in TLS.

### Patches
Patched in 0.6.2.


### References
- [kyberslash.cr.yp.to](https://kyberslash.cr.yp.to)
GitHub Security Advisory: GHSA-875g-mfp6-g7f9
Package: vmm-sys-util (RUST)
Severity: MODERATE (CVSS 5.7)
CWE: CWE-787: Out-of-bounds Write
Vulnerable versions: >= 0.5.0, < 0.12.0
Patched in: 0.12.0

Summary: `serde` deserialization for `FamStructWrapper` lacks bound checks that could potentially lead to out-of-bounds memory access

Details:
### Impact

An issue was discovered in the FamStructWrapper::deserialize implementation provided by the crate for vmm_sys_util::fam::FamStructWrapper, which can lead to out of bounds memory accesses. The deserialization does not check that the length stored in the header matches the flexible array length. Mismatch in the lengths might allow out of bounds memory access through Rust-safe methods.

Impacted versions: >= 0.5.0

### Patches

The issue was corrected in version 0.12.0 by inserting a check that verifies the lengths of compared flexible arrays are equal for any deserialized header and aborting deserialization otherwise. Moreover, the API was changed so that header length can only be modified through Rust-unsafe code. This ensures that users cannot trigger out-of-bounds memory access from Rust-safe code.
GitHub Security Advisory: GHSA-6ggr-cwv4-g7qg
Package: rosenpass (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-130: Improper Handling of Length Parameter Inconsistency
Vulnerable versions: < 0.2.1
Patched in: 0.2.1

Summary: Remotely exploitable denial of service in Rosenpass

Details:
Affected versions of this crate did not validate the size of buffers when attempting to decode messages.

This allows an attacker to trigger a panic by sending a UDP datagram with a 1 byte payload over network.

This flaw was corrected by validating the size of the buffers before attempting to decode the message.
GitHub Security Advisory: GHSA-r24f-hg58-vfrw
Package: unsafe-libyaml (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: < 0.2.10
Patched in: 0.2.10

Summary: unsafe-libyaml unaligned write of u64 on 32-bit and 16-bit platforms

Details:
Affected versions allocate memory using the alignment of `usize` and write data to it of type `u64`, without using `core::ptr::write_unaligned`. In platforms with sub-64bit alignment for `usize` (including wasm32 and x86) these writes are insufficiently aligned some of the time.

If using an ordinary optimized standard library, the bug exhibits Undefined Behavior so may or may not behave in any sensible way, depending on optimization settings and hardware and other things. If using a Rust standard library built with debug assertions enabled, the bug manifests deterministically in a crash (non-unwinding panic) saying _"ptr::write requires that the pointer argument is aligned and non-null"_.

No 64-bit platform is impacted by the bug.

The flaw was corrected by allocating with adequately high alignment on all
platforms.
GitHub Security Advisory: GHSA-x96g-95fq-4xv4
Package: ostree (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: < 0.17.1
Patched in: 0.17.1

Summary: libostree vulnerable to denial of service attack

Details:
An issue was discovered in ostree before version 0.17.1 allows attackers to cause a denial of service via the print_panic function in repo_checkout_filter.rs.
GitHub Security Advisory: GHSA-rjhf-4mh8-9xjq
Package: zerocopy (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 0.7.0, < 0.7.31
Patched in: 0.7.31

Summary: Zerocopy: Some Ref methods are unsound with some type parameters

Details:
The `Ref` methods `into_ref`, `into_mut`, `into_slice`, and `into_slice_mut` are unsound and may allow safe code to exhibit undefined behavior when used with `Ref<B, T>` where `B` is [`cell::Ref`](https://doc.rust-lang.org/core/cell/struct.Ref.html) or [`cell::RefMut`](https://doc.rust-lang.org/core/cell/struct.RefMut.html). Note that these methods remain sound when used with `B` types other than `cell::Ref` or `cell::RefMut`.

See https://github.com/google/zerocopy/issues/716 for a more in-depth analysis.

The current plan is to yank the affected versions soon. See https://github.com/google/zerocopy/issues/679 for more detail.
GitHub Security Advisory: GHSA-rjhf-4mh8-9xjq
Package: zerocopy (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 0.6.0, < 0.6.6
Patched in: 0.6.6

Summary: Zerocopy: Some Ref methods are unsound with some type parameters

Details:
The `Ref` methods `into_ref`, `into_mut`, `into_slice`, and `into_slice_mut` are unsound and may allow safe code to exhibit undefined behavior when used with `Ref<B, T>` where `B` is [`cell::Ref`](https://doc.rust-lang.org/core/cell/struct.Ref.html) or [`cell::RefMut`](https://doc.rust-lang.org/core/cell/struct.RefMut.html). Note that these methods remain sound when used with `B` types other than `cell::Ref` or `cell::RefMut`.

See https://github.com/google/zerocopy/issues/716 for a more in-depth analysis.

The current plan is to yank the affected versions soon. See https://github.com/google/zerocopy/issues/679 for more detail.
GitHub Security Advisory: GHSA-rjhf-4mh8-9xjq
Package: zerocopy (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 0.5.0, < 0.5.2
Patched in: 0.5.2

Summary: Zerocopy: Some Ref methods are unsound with some type parameters

Details:
The `Ref` methods `into_ref`, `into_mut`, `into_slice`, and `into_slice_mut` are unsound and may allow safe code to exhibit undefined behavior when used with `Ref<B, T>` where `B` is [`cell::Ref`](https://doc.rust-lang.org/core/cell/struct.Ref.html) or [`cell::RefMut`](https://doc.rust-lang.org/core/cell/struct.RefMut.html). Note that these methods remain sound when used with `B` types other than `cell::Ref` or `cell::RefMut`.

See https://github.com/google/zerocopy/issues/716 for a more in-depth analysis.

The current plan is to yank the affected versions soon. See https://github.com/google/zerocopy/issues/679 for more detail.
GitHub Security Advisory: GHSA-rjhf-4mh8-9xjq
Package: zerocopy (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 0.4.0, < 0.4.1
Patched in: 0.4.1

Summary: Zerocopy: Some Ref methods are unsound with some type parameters

Details:
The `Ref` methods `into_ref`, `into_mut`, `into_slice`, and `into_slice_mut` are unsound and may allow safe code to exhibit undefined behavior when used with `Ref<B, T>` where `B` is [`cell::Ref`](https://doc.rust-lang.org/core/cell/struct.Ref.html) or [`cell::RefMut`](https://doc.rust-lang.org/core/cell/struct.RefMut.html). Note that these methods remain sound when used with `B` types other than `cell::Ref` or `cell::RefMut`.

See https://github.com/google/zerocopy/issues/716 for a more in-depth analysis.

The current plan is to yank the affected versions soon. See https://github.com/google/zerocopy/issues/679 for more detail.
GitHub Security Advisory: GHSA-rjhf-4mh8-9xjq
Package: zerocopy (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 0.3.0, < 0.3.2
Patched in: 0.3.2

Summary: Zerocopy: Some Ref methods are unsound with some type parameters

Details:
The `Ref` methods `into_ref`, `into_mut`, `into_slice`, and `into_slice_mut` are unsound and may allow safe code to exhibit undefined behavior when used with `Ref<B, T>` where `B` is [`cell::Ref`](https://doc.rust-lang.org/core/cell/struct.Ref.html) or [`cell::RefMut`](https://doc.rust-lang.org/core/cell/struct.RefMut.html). Note that these methods remain sound when used with `B` types other than `cell::Ref` or `cell::RefMut`.

See https://github.com/google/zerocopy/issues/716 for a more in-depth analysis.

The current plan is to yank the affected versions soon. See https://github.com/google/zerocopy/issues/679 for more detail.
GitHub Security Advisory: GHSA-rjhf-4mh8-9xjq
Package: zerocopy (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 0.2.2, < 0.2.9
Patched in: 0.2.9

Summary: Zerocopy: Some Ref methods are unsound with some type parameters

Details:
The `Ref` methods `into_ref`, `into_mut`, `into_slice`, and `into_slice_mut` are unsound and may allow safe code to exhibit undefined behavior when used with `Ref<B, T>` where `B` is [`cell::Ref`](https://doc.rust-lang.org/core/cell/struct.Ref.html) or [`cell::RefMut`](https://doc.rust-lang.org/core/cell/struct.RefMut.html). Note that these methods remain sound when used with `B` types other than `cell::Ref` or `cell::RefMut`.

See https://github.com/google/zerocopy/issues/716 for a more in-depth analysis.

The current plan is to yank the affected versions soon. See https://github.com/google/zerocopy/issues/679 for more detail.
GitHub Security Advisory: GHSA-3mv5-343c-w2qg
Package: zerocopy (RUST)
Severity: LOW (CVSS 0.0)
Vulnerable versions: >= 0.7.0, < 0.7.31
Patched in: 0.7.31

Summary: Ref methods into_ref, into_mut, into_slice, and into_slice_mut are unsound when used with cell::Ref or cell::RefMut

Details:
*This advisory is also published as [RUSTSEC-2023-0074](https://rustsec.org/advisories/RUSTSEC-2023-0074.html).*

The `Ref` methods `into_ref`, `into_mut`, `into_slice`, and `into_slice_mut` are unsound and may allow safe code to exhibit undefined behavior when used with `Ref<B, T>` where `B` is [`cell::Ref`](https://doc.rust-lang.org/core/cell/struct.Ref.html) or [`cell::RefMut`](https://doc.rust-lang.org/core/cell/struct.RefMut.html). Note that these methods remain sound when used with `B` types other than `cell::Ref` or `cell::RefMut`.

See https://github.com/google/zerocopy/issues/716 for a more in-depth analysis.

The current plan is to yank the affected versions soon. See https://github.com/google/zerocopy/issues/679 for more detail.
GitHub Security Advisory: GHSA-3mv5-343c-w2qg
Package: zerocopy (RUST)
Severity: LOW (CVSS 0.0)
Vulnerable versions: >= 0.6.0, < 0.6.6
Patched in: 0.6.6

Summary: Ref methods into_ref, into_mut, into_slice, and into_slice_mut are unsound when used with cell::Ref or cell::RefMut

Details:
*This advisory is also published as [RUSTSEC-2023-0074](https://rustsec.org/advisories/RUSTSEC-2023-0074.html).*

The `Ref` methods `into_ref`, `into_mut`, `into_slice`, and `into_slice_mut` are unsound and may allow safe code to exhibit undefined behavior when used with `Ref<B, T>` where `B` is [`cell::Ref`](https://doc.rust-lang.org/core/cell/struct.Ref.html) or [`cell::RefMut`](https://doc.rust-lang.org/core/cell/struct.RefMut.html). Note that these methods remain sound when used with `B` types other than `cell::Ref` or `cell::RefMut`.

See https://github.com/google/zerocopy/issues/716 for a more in-depth analysis.

The current plan is to yank the affected versions soon. See https://github.com/google/zerocopy/issues/679 for more detail.
GitHub Security Advisory: GHSA-3mv5-343c-w2qg
Package: zerocopy (RUST)
Severity: LOW (CVSS 0.0)
Vulnerable versions: >= 0.5.0, < 0.5.2
Patched in: 0.5.2

Summary: Ref methods into_ref, into_mut, into_slice, and into_slice_mut are unsound when used with cell::Ref or cell::RefMut

Details:
*This advisory is also published as [RUSTSEC-2023-0074](https://rustsec.org/advisories/RUSTSEC-2023-0074.html).*

The `Ref` methods `into_ref`, `into_mut`, `into_slice`, and `into_slice_mut` are unsound and may allow safe code to exhibit undefined behavior when used with `Ref<B, T>` where `B` is [`cell::Ref`](https://doc.rust-lang.org/core/cell/struct.Ref.html) or [`cell::RefMut`](https://doc.rust-lang.org/core/cell/struct.RefMut.html). Note that these methods remain sound when used with `B` types other than `cell::Ref` or `cell::RefMut`.

See https://github.com/google/zerocopy/issues/716 for a more in-depth analysis.

The current plan is to yank the affected versions soon. See https://github.com/google/zerocopy/issues/679 for more detail.
GitHub Security Advisory: GHSA-3mv5-343c-w2qg
Package: zerocopy (RUST)
Severity: LOW (CVSS 0.0)
Vulnerable versions: = 0.4.0
Patched in: 0.4.1

Summary: Ref methods into_ref, into_mut, into_slice, and into_slice_mut are unsound when used with cell::Ref or cell::RefMut

Details:
*This advisory is also published as [RUSTSEC-2023-0074](https://rustsec.org/advisories/RUSTSEC-2023-0074.html).*

The `Ref` methods `into_ref`, `into_mut`, `into_slice`, and `into_slice_mut` are unsound and may allow safe code to exhibit undefined behavior when used with `Ref<B, T>` where `B` is [`cell::Ref`](https://doc.rust-lang.org/core/cell/struct.Ref.html) or [`cell::RefMut`](https://doc.rust-lang.org/core/cell/struct.RefMut.html). Note that these methods remain sound when used with `B` types other than `cell::Ref` or `cell::RefMut`.

See https://github.com/google/zerocopy/issues/716 for a more in-depth analysis.

The current plan is to yank the affected versions soon. See https://github.com/google/zerocopy/issues/679 for more detail.
GitHub Security Advisory: GHSA-3mv5-343c-w2qg
Package: zerocopy (RUST)
Severity: LOW (CVSS 0.0)
Vulnerable versions: >= 0.3.0, < 0.3.2
Patched in: 0.3.2

Summary: Ref methods into_ref, into_mut, into_slice, and into_slice_mut are unsound when used with cell::Ref or cell::RefMut

Details:
*This advisory is also published as [RUSTSEC-2023-0074](https://rustsec.org/advisories/RUSTSEC-2023-0074.html).*

The `Ref` methods `into_ref`, `into_mut`, `into_slice`, and `into_slice_mut` are unsound and may allow safe code to exhibit undefined behavior when used with `Ref<B, T>` where `B` is [`cell::Ref`](https://doc.rust-lang.org/core/cell/struct.Ref.html) or [`cell::RefMut`](https://doc.rust-lang.org/core/cell/struct.RefMut.html). Note that these methods remain sound when used with `B` types other than `cell::Ref` or `cell::RefMut`.

See https://github.com/google/zerocopy/issues/716 for a more in-depth analysis.

The current plan is to yank the affected versions soon. See https://github.com/google/zerocopy/issues/679 for more detail.