deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-jp37-5qhw-mffw
Package: sharks (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-334: Small Space of Random Values
Vulnerable versions: <= 0.5.0
Patched in: unpatched

Summary: Sharks has a Bias of Polynomial Coefficients in Secret Sharing

Details:
Affected versions of this crate allowed for a bias when generating random polynomials for Shamir Secret Sharing, where instead of being within the range `[0, 255]` they were instead in the range `[1, 255]`. A description from Cure53, who originally found the issue, is available:

> The correct method to select a random polynomial would be to select all coefficients (including the most significant coefficient) uniformly in the range 0..255 (inclusive). Otherwise, knowledge that a coefficient in a polynomial cannot be 0 permits the exclusion of single byte values for the shared secret given one share less than required. [...] Exploiting this weakness necessitates sharing the same secret multiple times. In this scenario, an attacker could exclude an exponential number of values for each of the shared bytes until sufficiently few values remain for brute forcing.  Cure53 estimates that under ideal circumstances (e.g., a 2-out-of-N scheme) a shared secret can be reconstructed if the same secret has been distributed 500-1500 times.

Secrets that have been shared a low amount of times (ideally, once) would not be impacted. However, secrets that are repeatedly shared may be vulnerable, especially if the shares are still available, and should be rotated.

The vulnerability does not impact reconstitution of secrets: secrets that have already been split can be recombined without issue.

The flaw can be corrected by changing the lower bound of the polynomial coefficient range in the `sharks::math::random_polynomial` function to `0`. The `blahaj` crate has been made available with a fixed version of the code, after attempts to reach the maintainer of the `sharks` crate were unsuccessful.
GitHub Security Advisory: GHSA-j3px-q95c-9683
Package: libz-rs-sys-cdylib (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: <= 0.3.1
Patched in: 0.4.0

Summary: zlib-rs stack overflow during decompression with malicious input

Details:
A denial of service vulnerability was found in zlib-rs, triggered by specially constructed input. This input causes a stack overflow, resulting in the process using zlib-rs to crash.

### Impact

Due to the way LLVM handles the zlib-rs codebase, tail calls were not guaranteed. This caused certain input patterns to result in a large number of stack frames being required, quickly resulting in a stack overflow. These are unlikely to occur in practice, but a dedicated attacker can construct malicious input files.

After stack overflows were found by @inahga with a fuzzer, we dove into the assembly, and found some cases where the stack grew

```asm
.LBB109_326:
    mov rdi, rbx
    call zlib_rs::inflate::State::type_do
    jmp .LBB109_311

.LBB109_311:
    lea rsp, [rbp - 40]
    pop rbx
    pop r12
    pop r13
    pop r14
    pop r15
    pop rbp
    .cfi_def_cfa rsp, 8
    ret
```

LLVM wants to centralize the cleanup before the return (many other blocks jump to `LBB109_311`), thereby invalidating a tail call to `type_do`. We were not able to get rid of this call without introducing one elsewhere: we just don't currently have the power to tell LLVM what we want it to do.

So, we switch back to loop+match waiting for changes to rust to make a more efficient implementation possible. Performance-wise, the damage is relatively minimal: we're just slower in cases where we already were slower than C. We are faster in cases where the relevant code is barely touched (in these cases the logic quickly moves into a hot inner loop and just spends most of its time there).

### Patches
Version 0.4.0 patches the problem and is no longer vulnerable.

### Workarounds
Users of zlib-rs should upgrade to the latest version. Users could alternatively run zlib-rs in a separate process to prevent a stack overflow crashing the entire program. In some situations a signal handler can be used to catch a stack overflow happening.
GitHub Security Advisory: GHSA-j3px-q95c-9683
Package: libz-rs-sys (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: <= 0.3.1
Patched in: 0.4.0

Summary: zlib-rs stack overflow during decompression with malicious input

Details:
A denial of service vulnerability was found in zlib-rs, triggered by specially constructed input. This input causes a stack overflow, resulting in the process using zlib-rs to crash.

### Impact

Due to the way LLVM handles the zlib-rs codebase, tail calls were not guaranteed. This caused certain input patterns to result in a large number of stack frames being required, quickly resulting in a stack overflow. These are unlikely to occur in practice, but a dedicated attacker can construct malicious input files.

After stack overflows were found by @inahga with a fuzzer, we dove into the assembly, and found some cases where the stack grew

```asm
.LBB109_326:
    mov rdi, rbx
    call zlib_rs::inflate::State::type_do
    jmp .LBB109_311

.LBB109_311:
    lea rsp, [rbp - 40]
    pop rbx
    pop r12
    pop r13
    pop r14
    pop r15
    pop rbp
    .cfi_def_cfa rsp, 8
    ret
```

LLVM wants to centralize the cleanup before the return (many other blocks jump to `LBB109_311`), thereby invalidating a tail call to `type_do`. We were not able to get rid of this call without introducing one elsewhere: we just don't currently have the power to tell LLVM what we want it to do.

So, we switch back to loop+match waiting for changes to rust to make a more efficient implementation possible. Performance-wise, the damage is relatively minimal: we're just slower in cases where we already were slower than C. We are faster in cases where the relevant code is barely touched (in these cases the logic quickly moves into a hot inner loop and just spends most of its time there).

### Patches
Version 0.4.0 patches the problem and is no longer vulnerable.

### Workarounds
Users of zlib-rs should upgrade to the latest version. Users could alternatively run zlib-rs in a separate process to prevent a stack overflow crashing the entire program. In some situations a signal handler can be used to catch a stack overflow happening.
GitHub Security Advisory: GHSA-j3px-q95c-9683
Package: zlib-rs (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: <= 0.3.1
Patched in: 0.4.0

Summary: zlib-rs stack overflow during decompression with malicious input

Details:
A denial of service vulnerability was found in zlib-rs, triggered by specially constructed input. This input causes a stack overflow, resulting in the process using zlib-rs to crash.

### Impact

Due to the way LLVM handles the zlib-rs codebase, tail calls were not guaranteed. This caused certain input patterns to result in a large number of stack frames being required, quickly resulting in a stack overflow. These are unlikely to occur in practice, but a dedicated attacker can construct malicious input files.

After stack overflows were found by @inahga with a fuzzer, we dove into the assembly, and found some cases where the stack grew

```asm
.LBB109_326:
    mov rdi, rbx
    call zlib_rs::inflate::State::type_do
    jmp .LBB109_311

.LBB109_311:
    lea rsp, [rbp - 40]
    pop rbx
    pop r12
    pop r13
    pop r14
    pop r15
    pop rbp
    .cfi_def_cfa rsp, 8
    ret
```

LLVM wants to centralize the cleanup before the return (many other blocks jump to `LBB109_311`), thereby invalidating a tail call to `type_do`. We were not able to get rid of this call without introducing one elsewhere: we just don't currently have the power to tell LLVM what we want it to do.

So, we switch back to loop+match waiting for changes to rust to make a more efficient implementation possible. Performance-wise, the damage is relatively minimal: we're just slower in cases where we already were slower than C. We are faster in cases where the relevant code is barely touched (in these cases the logic quickly moves into a hot inner loop and just spends most of its time there).

### Patches
Version 0.4.0 patches the problem and is no longer vulnerable.

### Workarounds
Users of zlib-rs should upgrade to the latest version. Users could alternatively run zlib-rs in a separate process to prevent a stack overflow crashing the entire program. In some situations a signal handler can be used to catch a stack overflow happening.
GitHub Security Advisory: GHSA-rp9h-rf7g-hwgr
Package: s2n-tls (RUST)
Severity: LOW (CVSS 0.0)
Vulnerable versions: < 0.3.7
Patched in: 0.3.7

Summary: s2n-tls has undefined behavior at process exit

Details:
### Impact
s2n-tls uses the Linux atexit function to register functions that clean up the global state when the process exits. In multi-threaded environments, the atexit handler may clean up state which is still in use by other threads. When this occurs, the exiting process may experience a segmentation fault or other undefined behavior. 

Customers of AWS services do not need to take action. Applications using s2n-tls should upgrade to the most recent release of s2n-tls.

**Impacted versions**: < v1.5.9.

### Patches
The patch commit [493b771](https://github.com/aws/s2n-tls/commit/493b77167dc367c394de23cfe78a029298e2a254) is included in s2n-tls v1.5.9 [1]

### Workarounds
The atexit handler may be disabled by calling `s2n_disable_atexit()` prior to initializing s2n-tls. The atexit handler is off by default in the patched versions. For further details, refer to [s2n-tls Usage Guide: Initialization and Teardown](https://github.com/aws/s2n-tls/blob/main/docs/usage-guide/topics/ch02-initialization.md).

If you have any questions or comments about this advisory, we ask that you contact AWS/Amazon Security via our vulnerability reporting page [2] or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.

[1] https://github.com/aws/s2n-tls/releases/tag/v1.5.9
[2] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting
GitHub Security Advisory: GHSA-g23h-7vf9-xc25
Package: mimalloc (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: < 0.1.39
Patched in: 0.1.39

Summary: Mimalloc Can Allocate Memory with Bad Alignment

Details:
This crate depended on a promise regarding alignments made by the author of the mimalloc allocator to avoid using aligned allocation functions where possible for performance reasons.
Since then, the mimalloc allocator's logic changed, making it break this promise.
This caused this crate to return memory with an incorrect alignment for some allocations, particularly those with large alignments.
The flaw was fixed by always using the aligned allocation functions.
GitHub Security Advisory: GHSA-fpr5-jp2j-4q2f
Package: paillier-zk (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-327: Use of a Broken or Risky Cryptographic Algorithm
Vulnerable versions: < 0.4.0
Patched in: 0.4.0

Summary: paillier-zk has ambiguous challenge derivation

Details:
Challenge derivation in non-interactive ZK proofs was ambiguous and that could lead to security vulnerability (however, it's unknown if it could be exploited).
GitHub Security Advisory: GHSA-rm66-9gh4-4gp8
Package: cggmp21 (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-327: Use of a Broken or Risky Cryptographic Algorithm
Vulnerable versions: < 0.4.0
Patched in: 0.4.0

Summary: cggmp21 vulnerable to ambiguous challenge derivation

Details:
Challenge derivation in non-interactive ZK proofs was ambiguous and that could lead to security vulnerability (however, it's unknown if it could be exploited).
GitHub Security Advisory: GHSA-pqpw-89w5-82v5
Package: simd-json-derive (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: < 0.12.0
Patched in: 0.12.0

Summary: `simd-json-derive` vulnerable to `MaybeUninit` misuse

Details:
An invalid use of `MaybeUninit::uninit().assume_init()` in `simd-json-derive`'s derive macro can cause undefined behavior. The original code used `MaybeUninit` to avoid initialisation of the struct and then set the fields using `ptr::write`. The undefined behavior triggered by this misuse of `MaybeUninit` can lead to invlaid memory access and panics in binaries compiled in release mode (aka simd-json-derive prior to version 0.12 has UB and optimizes into some nonsense)

The version `0.12.0` removes this section of code, avoiding the use of MaybeUninit alltogether.
GitHub Security Advisory: GHSA-7jjx-3qw9-j6h6
Package: cggmp21-keygen (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-327: Use of a Broken or Risky Cryptographic Algorithm
Vulnerable versions: < 0.3.0
Patched in: 0.3.0

Summary: cggmp21-keygen has ambiguous challenge derivation

Details:
Challenge derivation in non-interactive ZK proofs was ambiguous and that could lead to security vulnerability (however, it's unknown if it could be exploited).
GitHub Security Advisory: GHSA-x8jh-xj3x-gx3c
Package: fast-float (RUST)
Severity: LOW (CVSS 0.0)
Vulnerable versions: <= 0.2.0
Patched in: unpatched

Summary: `fast-float` has multiple soundness issues

Details:
`fast-float` contains multiple soundness issues:

 1. [Undefined behavior when checking input length](https://github.com/aldanor/fast-float-rust/issues/28), which has been merged but no package [pubished](https://github.com/aldanor/fast-float-rust/issues/35).
 1. [Many functions marked as safe with non-local safety guarantees](https://github.com/aldanor/fast-float-rust/issues/37)

The library is also unmaintained.

## Alternatives

For quickly parsing floating-point numbers third-party crates are generally 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. When requiring direct parsing from bytes and/or partial parsers, the [`fast-float2`](https://crates.io/crates/fast-float2) fork of `fast-float` containing these security patches and reduces overall usage of unsafe.
GitHub Security Advisory: GHSA-fmq6-4w57-2w3v
Package: wasm3 (RUST)
Severity: MODERATE (CVSS 8.4)
CWE: CWE-125: Out-of-bounds Read, CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: <= 0.3.1
Patched in: unpatched

Summary: wasm3 uncontrolled memory allocation vulnerability

Details:
wasm3 at commit 139076a contains a memory leak in the Read_utf8 function.
GitHub Security Advisory: GHSA-8m24-3cfx-9fjw
Package: sp1-recursion-circuit (RUST)
Severity: LOW (CVSS 0.0)
Vulnerable versions: < 3.0.0
Patched in: 3.0.0

Summary: sp1 has insufficient observation of cumulative sum

Details:
During proof generation, the prover must observe all values sent to the verifier to generate valid Fiat-Shamir challenges. Prior to v3.0.0 the cumulative sum of the permutation argument was not observed when sampling zeta, which is a random challenge sampled to force the constraints to be true. In v3.0.0, this is fixed by observing the cumulative sum into the challenger, which can is done by observing the commit to the entire permutation trace.

While this vulnerability is theoretically present in v2.0.0 and below, exploiting it is quite a difficult task as the cumulative sum one can get from manipulation is essentially random. It requires practically infeasible amount of computation and deep knowledge of cryptographic attacks to carry out.

This issue was discovered during the audit of SP1 V3.0.0 and was officially fixed on October 17th. Out of abundance of caution, we will be deprecating all versions of SP1 before 3.0.0.
GitHub Security Advisory: GHSA-hxf5-99xg-86hw
Package: cap-primitives (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 3.4.1
Patched in: 3.4.1

Summary: cap-std doesn't fully sandbox all the Windows device filenames

Details:
### Impact

cap-std'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 filesystem paths could bypass the sandbox and access devices through those special device filenames with superscript digits, and through them provide 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

The bug is fixed in https://github.com/bytecodealliance/cap-std/pull/371, which is published in cap-primitives 3.4.1, cap-std 3.4.1, and cap-async-std 3.4.1.

### 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)
 - https://github.com/bytecodealliance/cap-std/pull/371
GitHub Security Advisory: GHSA-hxf5-99xg-86hw
Package: cap-async-std (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 3.4.1
Patched in: 3.4.1

Summary: cap-std doesn't fully sandbox all the Windows device filenames

Details:
### Impact

cap-std'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 filesystem paths could bypass the sandbox and access devices through those special device filenames with superscript digits, and through them provide 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

The bug is fixed in https://github.com/bytecodealliance/cap-std/pull/371, which is published in cap-primitives 3.4.1, cap-std 3.4.1, and cap-async-std 3.4.1.

### 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)
 - https://github.com/bytecodealliance/cap-std/pull/371
GitHub Security Advisory: GHSA-hxf5-99xg-86hw
Package: cap-std (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 3.4.1
Patched in: 3.4.1

Summary: cap-std doesn't fully sandbox all the Windows device filenames

Details:
### Impact

cap-std'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 filesystem paths could bypass the sandbox and access devices through those special device filenames with superscript digits, and through them provide 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

The bug is fixed in https://github.com/bytecodealliance/cap-std/pull/371, which is published in cap-primitives 3.4.1, cap-std 3.4.1, and cap-async-std 3.4.1.

### 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)
 - https://github.com/bytecodealliance/cap-std/pull/371
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: = 26.0.0
Patched in: 26.0.1

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-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: >= 25.0.0, < 25.0.3
Patched in: 25.0.3

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)