deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-gw5p-q8mj-p7gh
Package: wasmtime (RUST)
Severity: LOW (CVSS 2.2)
CWE: CWE-193: Off-by-one Error
Vulnerable versions: >= 11.0.0, < 11.0.2
Patched in: 11.0.2

Summary: Miscompilation of wasm `i64x2.shr_s` instruction with constant input on x86_64

Details:
### Impact

Wasmtime versions from 10.0.0 to 12.0.1 contain a miscompilation of the WebAssembly `i64x2.shr_s` instruction on x86_64 platforms when the shift amount is a constant value that is larger than 32. Only x86_64 is affected so all other targets are not affected by this. The miscompilation results in the instruction producing an incorrect result, namely the low 32-bits of the second lane of the vector are derived from the low 32-bits of the second lane of the input vector instead of the high 32-bits. The primary impact of this issue is that any WebAssembly program using the `i64x2.shr_s` with a constant shift amount larger than 32 may produce an incorrect result.

This issue is not an escape from the WebAssembly sandbox. Execution of WebAssembly guest programs will still behave correctly with respect to memory sandboxing and isolation from the host. Wasmtime considers non-spec-compliant behavior as a security issue nonetheless.

This issue was discovered through fuzzing of Wasmtime's code generator Cranelift.

### Patches

Wasmtime versions 10.0.2, 11.0.2, and 12.0.2 are all patched to no longer have this miscompilation.

### Workarounds

This issue only affects x86_64 hosts and the only workaround is to either scan for this pattern in wasm modules which is nontrivial or to [disable the SIMD proposal for WebAssembly](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.wasm_simd). Users prior to 10.0.0 are unaffected by this vulnerability.

### References

* [PR which introduced this bug to Wasmtime](https://github.com/bytecodealliance/wasmtime/pull/6372)
* [Mailing list announcement](https://groups.google.com/a/bytecodealliance.org/g/sec-announce/c/B8PJgg6bEdg)
GitHub Security Advisory: GHSA-gw5p-q8mj-p7gh
Package: wasmtime (RUST)
Severity: LOW (CVSS 2.2)
CWE: CWE-193: Off-by-one Error
Vulnerable versions: >= 10.0.0, < 10.0.2
Patched in: 10.0.2

Summary: Miscompilation of wasm `i64x2.shr_s` instruction with constant input on x86_64

Details:
### Impact

Wasmtime versions from 10.0.0 to 12.0.1 contain a miscompilation of the WebAssembly `i64x2.shr_s` instruction on x86_64 platforms when the shift amount is a constant value that is larger than 32. Only x86_64 is affected so all other targets are not affected by this. The miscompilation results in the instruction producing an incorrect result, namely the low 32-bits of the second lane of the vector are derived from the low 32-bits of the second lane of the input vector instead of the high 32-bits. The primary impact of this issue is that any WebAssembly program using the `i64x2.shr_s` with a constant shift amount larger than 32 may produce an incorrect result.

This issue is not an escape from the WebAssembly sandbox. Execution of WebAssembly guest programs will still behave correctly with respect to memory sandboxing and isolation from the host. Wasmtime considers non-spec-compliant behavior as a security issue nonetheless.

This issue was discovered through fuzzing of Wasmtime's code generator Cranelift.

### Patches

Wasmtime versions 10.0.2, 11.0.2, and 12.0.2 are all patched to no longer have this miscompilation.

### Workarounds

This issue only affects x86_64 hosts and the only workaround is to either scan for this pattern in wasm modules which is nontrivial or to [disable the SIMD proposal for WebAssembly](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.wasm_simd). Users prior to 10.0.0 are unaffected by this vulnerability.

### References

* [PR which introduced this bug to Wasmtime](https://github.com/bytecodealliance/wasmtime/pull/6372)
* [Mailing list announcement](https://groups.google.com/a/bytecodealliance.org/g/sec-announce/c/B8PJgg6bEdg)
GitHub Security Advisory: GHSA-6jmw-6mxw-w4jc
Package: bcder (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-228: Improper Handling of Syntactically Invalid Structure, CWE-232: Improper Handling of Undefined Values
Vulnerable versions: < 0.7.3
Patched in: 0.7.3

Summary: BER/CER/DER decoder panics on invalid input

Details:
NLnet Labs’ bcder library up to and including version 0.7.2 panics while decoding certain invalid input data rather than rejecting the data with an error. This can affect both the actual decoding stage as well as accessing content of types that utilized delayed decoding.
GitHub Security Advisory: GHSA-j7hp-h8jx-5ppr
Package: libwebp-sys2 (RUST)
Severity: HIGH (CVSS 8.8)
CWE: CWE-787: Out-of-bounds Write
Vulnerable versions: < 0.1.8
Patched in: 0.1.8

Summary: libwebp: OOB write in BuildHuffmanTable

Details:
Heap buffer overflow in libwebp allow a remote attacker to perform an out of bounds memory write via a crafted HTML page.
GitHub Security Advisory: GHSA-36xm-35qq-795w
Package: inventory (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: < 0.2.0
Patched in: 0.2.0

Summary: Inventory exposes reference to non-Sync data to an arbitrary thread

Details:
Affected versions do not enforce a `Sync` bound on the type of caller-provided value held in the plugin registry. References to these values are made accessible to arbitrary threads other than the one that constructed them.

A caller could use this flaw to submit thread-unsafe data into inventory, then access it as a reference simultaneously from multiple threads.

The flaw was corrected by enforcing that data submitted by the caller into inventory is `Sync`.
GitHub Security Advisory: GHSA-jcr6-4frq-9gjj
Package: users (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: <= 0.11.0
Patched in: unpatched

Summary: Users vulnerable to unaligned read of `*const *const c_char` pointer

Details:
Affected versions dereference a potentially unaligned pointer. The pointer is commonly unaligned in practice, resulting in undefined behavior.

In some build modes, this is observable as a panic followed by abort. In other build modes the UB may manifest in some other way, including the possibility of working correctly in some architectures.

The crate is not currently maintained, so a patched version is not available.

## Recommended alternatives
- [`uzers`](https://crates.io/crates/uzers) (an actively maintained fork of the `users` crate)
- [`sysinfo`](https://crates.io/crates/sysinfo)
GitHub Security Advisory: GHSA-ghc8-5cgm-5rpf
Package: inventory (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: < 0.2.0
Patched in: 0.2.0

Summary: Inventory fails to prohibit standard library access prior to initialization of Rust standard library runtime

Details:
Affected versions allow arbitrary caller-provided code to execute before the lifetime of `main`.

If the caller-provided code accesses particular pieces of the standard library that require an initialized Rust runtime, such as `std::io` or `std::thread`, these may not behave as documented. Panics are likely; UB is possible.

The flaw was corrected by enforcing that only code written within the `inventory` crate, which is guaranteed not to access runtime-dependent parts of the standard library, runs before `main`. Caller-provided code is restricted to running at compile time.
GitHub Security Advisory: GHSA-83mx-573x-5rw9
Package: openssl-src (RUST)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-476: NULL Pointer Dereference
Vulnerable versions: < 111.15.0
Patched in: 111.15.0

Summary: openssl-src NULL pointer Dereference in signature_algorithms processing

Details:
An OpenSSL TLS server may crash if sent a maliciously crafted renegotiation ClientHello message from a client. If a TLSv1.2 renegotiation ClientHello omits the signature_algorithms extension (where it was present in the initial ClientHello), but includes a signature_algorithms_cert extension then a NULL pointer dereference will result, leading to a crash and a denial of service attack. A server is only vulnerable if it has TLSv1.2 and renegotiation enabled (which is the default configuration). OpenSSL TLS clients are not impacted by this issue. All OpenSSL 1.1.1 versions are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1k. OpenSSL 1.0.2 is not impacted by this issue. Fixed in OpenSSL 1.1.1k (Affected 1.1.1-1.1.1j).
GitHub Security Advisory: GHSA-49hh-fprx-m68g
Package: vm-memory (RUST)
Severity: LOW (CVSS 2.5)
CWE: CWE-125: Out-of-bounds Read
Vulnerable versions: < 0.12.2
Patched in: 0.12.2

Summary: Default functions in VolatileMemory trait lack bounds checks, potentially leading to out-of-bounds memory accesses

Details:
### Impact
An issue was discovered in the default implementations of the `VolatileMemory::{get_atomic_ref, aligned_as_ref, aligned_as_mut, get_ref, get_array_ref}` trait functions, which allows out-of-bounds memory access if the `VolatileMemory::get_slice` function returns a `VolatileSlice` whose length is less than the function’s `count` argument. No implementations of `get_slice` provided in `vm_memory` are affected. Users of custom `VolatileMemory` implementations may be impacted if the custom implementation does not adhere to `get_slice`'s documentation.

### Patches
The issue started in version 0.1.0 but was fixed in version 0.12.2 by inserting a check that verifies that the `VolatileSlice` returned by `get_slice` is of the correct length.

### Workarounds
Not Required

### References
https://github.com/rust-vmm/vm-memory/commit/aff1dd4a5259f7deba56692840f7a2d9ca34c9c8
https://crates.io/crates/vm-memory/0.12.2
GitHub Security Advisory: GHSA-5m39-wx2q-mxg3
Package: lzf (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: < 0.3.2
Patched in: 0.3.2

Summary: Invalid use of `mem::uninitialized` causes `use-of-uninitialized-value`

Details:
The compression and decompression function used `mem:uninitialized` to create an array of uninitialized values, to later write values into it. This later leads to reads from uninitialized memory.

The flaw was corrected in commit b633bf265e41c60dfce3be7eac4e4dd5e18d06cf by using a heap-allocated `Vec` and removing out use of `mem::uninitialized`. The fix was released in v0.3.2 and v1.0.0

Subsequently, the crate was deprecated and its use is discouraged.
GitHub Security Advisory: GHSA-wrvc-72w7-xpmj
Package: sodiumoxide (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-697: Incorrect Comparison
Vulnerable versions: >= 0.2.0, < 0.2.5
Patched in: 0.2.5

Summary: Incorrect Comparison in sodiumoxide

Details:
An issue was discovered in the sodiumoxide crate starting with 0.2.0 and prior to 0.2.5 for Rust. `generichash::Digest::eq` compares itself to itself and thus has degenerate security properties.
GitHub Security Advisory: GHSA-hrjm-c879-pp86
Package: libsecp256k1 (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-208: Observable Timing Discrepancy
Vulnerable versions: < 0.3.1
Patched in: 0.3.1

Summary: libsecp256k1 contains side-channel timing attack

Details:
Versions of libsecp256k1 prior to 0.3.1 did not execute `Scalar::check_overflow` in constant time. This allows an attacker to potentially leak information via a timing attack. The flaw was corrected by modifying `Scalar::check_overflow` to execute in constant time.
GitHub Security Advisory: GHSA-r98r-j25q-rmpr
Package: failure (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-843: Access of Resource Using Incompatible Type ('Type Confusion')
Vulnerable versions: <= 0.1.8
Patched in: unpatched

Summary: Rust Failure Crate Vulnerable to Type confusion

Details:
Safe Rust code can implement malfunctioning `__private_get_type_id__` and cause type confusion when downcasting, which is an undefined behavior.

Users who derive Fail trait are not affected.
GitHub Security Advisory: GHSA-rcx8-48pc-v9q8
Package: mail-internals (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 0.2.0, <= 0.2.3
Patched in: unpatched

Summary: mail-internals use-after-free vulnerability in `vec_insert_bytes`

Details:
Incorrect reallocation logic in the function [`vec_insert_bytes`](https://docs.rs/mail-internals/0.2.3/mail_internals/utils/fn.vec_insert_bytes.html) causes a use-after-free.

This function does not have to be called directly to trigger the vulnerability because many methods on [`EncodingWriter`](https://docs.rs/mail-internals/0.2.3/mail_internals/encoder/struct.EncodingWriter.html) call this function internally.

The mail-\* suite is unmaintained and the upstream sources have been actively vandalised.
A fixed `mail-internals-ng` (and `mail-headers-ng` and `mail-core-ng`) crate has been published which fixes this, and a dependency on another unsound crate.
GitHub Security Advisory: GHSA-37xq-q42p-rv3p
Package: ntpd (RUST)
Severity: LOW (CVSS 2.6)
CWE: CWE-1395: Dependency on Vulnerable Third-Party Component
Vulnerable versions: < 0.3.7
Patched in: 0.3.7

Summary: ntpd has Dependency on Vulnerable Third-Party Component

Details:
During startup, an attacker that can man-in-the-middle traffic to and from NTS key exchange servers can trigger a very expensive key validation process due to a vulnerability in webpki.

### Impact
This vulnerability can lead to excessive cpu usage on startup on clients configured to use NTS

### Patches
Affected users are recommended to upgrade to version 0.3.7

### References
See also https://github.com/rustsec/advisory-db/blob/main/crates/rustls-webpki/RUSTSEC-2023-0053.md
GitHub Security Advisory: GHSA-fh2r-99q2-6mmg
Package: rustls-webpki (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: >= 0.101.0, < 0.101.4
Patched in: 0.101.4

Summary: rustls-webpki: CPU denial of service in certificate path building

Details:
When this crate is given a pathological certificate chain to validate, it will spend CPU time exponential with the number of candidate certificates at each step of path building.

Both TLS clients and TLS servers that accept client certificate are affected.

We now give each path building operation a budget of 100 signature verifications.

The original `webpki` crate is also affected, see [GHSA-8qv2-5vq6-g2g7](https://github.com/advisories/GHSA-8qv2-5vq6-g2g7).

This was previously reported in the original crate <https://github.com/briansmith/webpki/issues/69> and re-reported to us recently.
GitHub Security Advisory: GHSA-fh2r-99q2-6mmg
Package: rustls-webpki (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: < 0.100.2
Patched in: 0.100.2

Summary: rustls-webpki: CPU denial of service in certificate path building

Details:
When this crate is given a pathological certificate chain to validate, it will spend CPU time exponential with the number of candidate certificates at each step of path building.

Both TLS clients and TLS servers that accept client certificate are affected.

We now give each path building operation a budget of 100 signature verifications.

The original `webpki` crate is also affected, see [GHSA-8qv2-5vq6-g2g7](https://github.com/advisories/GHSA-8qv2-5vq6-g2g7).

This was previously reported in the original crate <https://github.com/briansmith/webpki/issues/69> and re-reported to us recently.
GitHub Security Advisory: GHSA-gq4p-4hxv-5rg9
Package: wasm3 (RUST)
Severity: MODERATE (CVSS 5.5)
CWE: CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer, CWE-125: Out-of-bounds Read
Vulnerable versions: <= 0.5.0
Patched in: unpatched

Summary: WASM3 segmentation fault

Details:
WASM3 v0.5.0 was discovered to contain a segmentation fault via the component `Compile_Memory_CopyFill`.
GitHub Security Advisory: GHSA-8rwr-x37p-mx23
Package: openssl-src (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow'), CWE-787: Out-of-bounds Write
Vulnerable versions: >= 300.0.0, < 300.0.11
Patched in: 300.0.11

Summary: X.509 Email Address 4-byte Buffer Overflow

Details:
A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Note that this occurs
after certificate chain signature verification and requires either a CA to have signed the malicious certificate or for the application to
continue certificate verification despite failure to construct a path to a trusted issuer. An attacker can craft a malicious email address
to overflow four attacker-controlled bytes on the stack. This buffer overflow could result in a crash (causing a denial of service) or
potentially remote code execution.

Many platforms implement stack overflow protections which would mitigate against the risk of remote code execution. The risk may be further mitigated based on stack layout for any given platform/compiler.

Pre-announcements of CVE-2022-3602 described this issue as CRITICAL. Further analysis based on some of the mitigating factors described above have led this to be downgraded to HIGH. Users are still encouraged to upgrade to a new version as soon as possible.

In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects.
GitHub Security Advisory: GHSA-fc7x-2cmc-8j2g
Package: sha2 (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-327: Use of a Broken or Risky Cryptographic Algorithm
Vulnerable versions: = 0.9.7
Patched in: 0.9.8

Summary: Incorrect hash in sha2

Details:
The v0.9.7 release of the sha2 crate introduced a new AVX2-accelerated backend which was automatically enabled for all x86/x86_64 CPUs where AVX2 support was autodetected at runtime.

This backend was buggy and would miscompute results for long messages (i.e. messages spanning multiple SHA blocks).

The crate has since been yanked, but any users who upgraded to v0.9.7 should immediately upgrade to v0.9.8 and recompute any hashes which were previously computed by v0.9.7.
GitHub Security Advisory: GHSA-h6xw-mghq-7523
Package: Simple-Wayland-HotKey-Daemon (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 1.2.0
Patched in: 1.2.0

Summary: Unsafe parsing in SWHKD

Details:
SWHKD 1.1.5 allows unsafe parsing via the -c option. An information leak might occur but there is a simple denial of service (memory exhaustion) upon an attempt to parse a large or infinite file (such as a block or character device).
GitHub Security Advisory: GHSA-crf8-h2wq-2h9x
Package: wasm3 (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-20: Improper Input Validation, CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer
Vulnerable versions: <= 0.5.0
Patched in: unpatched

Summary: WASM3 Improper Input Validation vulnerability

Details:
WASM3 v0.5.0 was discovered to contain a segmentation fault via the component `op_Select_i32_srs` in `wasm3/source/m3_exec.h`.
GitHub Security Advisory: GHSA-9p8q-j6q5-mjw8
Package: galois_2p8 (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow'), CWE-193: Off-by-one Error
Vulnerable versions: < 0.1.2
Patched in: 0.1.2

Summary: Buffer Overflow in galois_2p8

Details:
In galois_2p8 before 0.1.2, PrimitivePolynomialField::new has an off-by-one buffer overflow for a vector.
GitHub Security Advisory: GHSA-g323-fr93-4j3c
Package: openssl-src (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-404: Improper Resource Shutdown or Release, CWE-459: Incomplete Cleanup
Vulnerable versions: >= 300.0.0, < 300.0.6
Patched in: 300.0.6

Summary: Resource leakage when decoding certificates and keys

Details:
The OPENSSL_LH_flush() function, which empties a hash table, contains a bug that breaks reuse of the memory occuppied by the removed hash table entries. This function is used when decoding certificates or keys. If a long lived process periodically decodes certificates or keys its memory usage will expand without bounds and the process might be terminated by the operating system causing a denial of service. Also traversing the empty hash table entries will take increasingly more time. Typically such long lived processes might be TLS clients or TLS servers configured to accept client certificate authentication. The function was added in the OpenSSL 3.0 version thus older releases are not affected by the issue. Fixed in OpenSSL 3.0.3 (Affected 3.0.0,3.0.1,3.0.2).
GitHub Security Advisory: GHSA-9hfg-pxr6-q4vp
Package: crypto2 (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer
Vulnerable versions: <= 0.1.2
Patched in: unpatched

Summary: Use of a Broken or Risky Cryptographic Algorithm in crypto2

Details:
The implementation does not enforce alignment requirements on input slices while incorrectly assuming 4-byte alignment through an unsafe call to std::slice::from_raw_parts_mut, which breaks the contract and introduces undefined behavior.

This affects Chacha20 encryption and decryption in crypto2.
GitHub Security Advisory: GHSA-xvv9-5j67-3rpq
Package: zola (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: >= 0.13.0, <= 0.17.2
Patched in: unpatched

Summary: zola Path Traversal vulnerability

Details:
An issue was discovered in zola 0.13.0 through 0.17.2. The custom implementation of a web server, available via the "zola serve" command, allows directory traversal. The `handle_request` function, used by the server to process HTTP requests, does not account for sequences of special path control characters (`../`) in the URL when serving a file, which allows one to escape the webroot of the server and read arbitrary files from the filesystem.
GitHub Security Advisory: GHSA-w5vr-6qhr-36cc
Package: ed25519-dalek (RUST)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-497: Exposure of Sensitive System Information to an Unauthorized Control Sphere
Vulnerable versions: < 2.0.0
Patched in: 2.0.0

Summary: `ed25519-dalek` Double Public Key Signing Function Oracle Attack

Details:
Versions of `ed25519-dalek` prior to v2.0 model private and public keys as separate types which can be assembled into a `Keypair`, and also provide APIs for serializing and deserializing 64-byte private/public keypairs.

Such APIs and serializations are inherently unsafe as the public key is one of the inputs used in the deterministic computation of the `S` part of the signature, but not in the `R` value. An adversary could somehow use the signing function as an oracle that allows arbitrary public keys as input can obtain two signatures for the same message sharing the same `R` and only differ on the `S` part.

Unfortunately, when this happens, one can easily extract the private key.

Revised public APIs in v2.0 of `ed25519-dalek` do NOT allow a decoupled private/public keypair as signing input, except as part of specially labeled "hazmat" APIs which are clearly labeled as being dangerous if misused.