deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-9f9p-cp3c-72jf
Package: trillium-http (RUST)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting'), CWE-436: Interpretation Conflict
Vulnerable versions: < 0.3.12
Patched in: 0.3.12

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

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

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

### Patches

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

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

### Workarounds

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

### Impact

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

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

@divergentdave filed this vulnerability many months ago but I did not see it until the evening of Jan 23, 2024. Patches were issued less than 24h after reading the vulnerability. The [security policy](https://github.com/trillium-rs/trillium/blob/main/SECURITY.md) has been [updated](https://github.com/trillium-rs/trillium/commit/b27950ceae52aa7a0f482494fe67b6069234d417) to avoid delays like this in the future.
GitHub Security Advisory: GHSA-c8v3-jhv9-4ppc
Package: rust-i18n-support (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-416: Use After Free
Vulnerable versions: >= 3.0.0, < 3.0.1
Patched in: 3.0.1

Summary: Use-after-free when setting the locale

Details:
Version 3.0.0 introduced an `AtomicStr` type, that is used to store the current locale. It stores the locale as a raw pointer to an `Arc<String>`. The locale can be read with `AtomicStr::as_str()`. `AtomicStr::as_str()` does not increment the usage counter of the `Arc`.

If the locale is changed in one thread, another thread can have a stale -- possibly already freed -- reference to the stored string.
GitHub Security Advisory: GHSA-w59h-378f-2frm
Package: threadalone (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: < 0.2.1
Patched in: 0.2.1

Summary: Unsound sending of non-Send types across threads in threadalone

Details:
Affected versions can run the `Drop` impl of a non-Send type on a different
thread than it was created on.

The flaw occurs when a stderr write performed by the `threadalone` crate fails,
for example because stderr is redirected to a location on a filesystem that is
full, or because stderr is a pipe that has been closed by the reader.

Dropping a non-Send type on the wrong thread is unsound. If used with a type
such as a pthread-based `MutexGuard`, [the consequence is undefined
behavior][mutexguard]. If used with `Rc`, there would be a data race on the
reference count, which is likewise undefined behavior.

[mutexguard]: https://github.com/rust-lang/rust/issues/23465#issuecomment-82730326
GitHub Security Advisory: GHSA-r7qv-8r2h-pg27
Package: shlex (RUST)
Severity: LOW (CVSS 3.2)
Vulnerable versions: < 1.3.0
Patched in: 1.3.0

Summary: Multiple issues involving quote API in shlex

Details:
## Issue 1: Failure to quote characters

Affected versions of this crate allowed the bytes `{` and `\xa0` to appear unquoted and unescaped in command arguments.

If the output of `quote` or `join` is passed to a shell, then what should be a single command argument could be interpreted as multiple arguments.

This does not *directly* allow arbitrary command execution (you can't inject a command substitution or similar).  But depending on the command you're running, being able to inject multiple arguments where only one is expected could lead to undesired consequences, potentially including arbitrary command execution.

The flaw was corrected in version 1.2.1 by escaping additional characters. Updating to 1.3.0 is recommended, but 1.2.1 offers a more minimal fix if desired.

Workaround: Check for the bytes `{` and `\xa0` in `quote`/`join` input or output.

(Note: `{` is problematic because it is used for glob expansion.  `\xa0` is problematic because it's treated as a word separator in [specific environments][solved-xa0].)

## Issue 2: Dangerous API w.r.t. nul bytes

Version 1.3.0 deprecates the `quote` and `join` APIs in favor of `try_quote` and `try_join`, which behave the same except that they have `Result` return type, returning `Err` if the input contains nul bytes.

Strings containing nul bytes generally cannot be used in Unix command arguments or environment variables, and most shells cannot handle nul bytes even internally.  If you try to pass one anyway, then the results might be security-sensitive in uncommon scenarios.  [More details here.][nul-bytes]

Due to the low severity, the behavior of the original `quote` and `join` APIs has not changed; they continue to allow nuls.

Workaround: Manually check for nul bytes in `quote`/`join` input or output.

## Issue 3: Lack of documentation for interactive shell risks

The `quote` family of functions does not and cannot escape control characters. With non-interactive shells this is perfectly safe, as control characters have no special effect.  But if you writing directly to the standard input of an interactive shell (or through a pty), then control characters [can cause misbehavior including arbitrary command injection.][control-characters]

This is essentially unfixable, and has not been patched.  But as of version 1.3.0, documentation has been added.

Future versions of `shlex` may add API variants that avoid the issue at the cost of reduced portability.

[solved-xa0]: https://docs.rs/shlex/latest/shlex/quoting_warning/index.html#solved-xa0
[nul-bytes]: https://docs.rs/shlex/latest/shlex/quoting_warning/index.html#nul-bytes
[control-characters]: https://docs.rs/shlex/latest/shlex/quoting_warning/index.html#control-characters-interactive-contexts-only
GitHub Security Advisory: GHSA-58j9-j2fj-v8f4
Package: surrealdb (RUST)
Severity: HIGH (CVSS 7.5)
Vulnerable versions: < 1.1.0
Patched in: 1.1.0

Summary: SurrealDB vulnerable to Uncontrolled CPU Consumption via WebSocket Interface

Details:
SurrealDB depends on the `tungstenite` and `tokio-tungstenite` crates used by the `axum` crate, which handles connections to the SurrealDB WebSocket interface. On versions before `0.20.1`, the `tungstenite` crate presented an issue which allowed the parsing of HTTP headers during the client handshake to continuously consume high CPU when the headers were very long. All affected crates have been updated in SurrealDB version `1.1.0`.

From the original advisory for [CVE-2023-43669](https://nvd.nist.gov/vuln/detail/CVE-2023-43669):
"The Tungstenite crate through 0.20.0 for Rust allows remote attackers to cause a denial of service (minutes of CPU consumption) via an excessive length of an HTTP header in a client handshake. The length affects both how many times a parse is attempted (e.g., thousands of times) and the average amount of data for each parse attempt (e.g., millions of bytes)."

### Impact

A remote unauthenticated attacker may cause a SurrealDB server that exposes its WebSocket interface to consume high CPU by sending an HTTP request with a very long header to the WebSocket interface, potentially leading to denial of service.

### Patches

- Version 1.1.0 and later are not affected by this issue.

### Workarounds

Users unable to update may be able to limit access to the WebSocket interface (i.e. the `/rpc` endpoint) via reverse proxy if not in use or only used by a limited number of trusted clients. Alternatively, a reverse proxy may be used to strip or truncate request headers exceeding a reasonable length before reaching the SurrealDB server.

### References

- #2807
- https://nvd.nist.gov/vuln/detail/CVE-2023-43669
- https://rustsec.org/advisories/RUSTSEC-2023-0065.html
- https://github.com/snapview/tungstenite-rs/issues/376
GitHub Security Advisory: GHSA-8r5v-vm4m-4g25
Package: h2 (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 0.4.0, < 0.4.2
Patched in: 0.4.2

Summary: Resource exhaustion vulnerability in h2 may lead to Denial of Service (DoS)

Details:
An attacker with an HTTP/2 connection to an affected endpoint can send a steady stream of invalid frames to force the
generation of reset frames on the victim endpoint.
By closing their recv window, the attacker could then force these resets to be queued in an unbounded fashion,
resulting in Out Of Memory (OOM) and high CPU usage.

This fix is corrected in [hyperium/h2#737](https://github.com/hyperium/h2/pull/737), which limits the total number of
internal error resets emitted by default before the connection is closed.
GitHub Security Advisory: GHSA-8r5v-vm4m-4g25
Package: h2 (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: < 0.3.24
Patched in: 0.3.24

Summary: Resource exhaustion vulnerability in h2 may lead to Denial of Service (DoS)

Details:
An attacker with an HTTP/2 connection to an affected endpoint can send a steady stream of invalid frames to force the
generation of reset frames on the victim endpoint.
By closing their recv window, the attacker could then force these resets to be queued in an unbounded fashion,
resulting in Out Of Memory (OOM) and high CPU usage.

This fix is corrected in [hyperium/h2#737](https://github.com/hyperium/h2/pull/737), which limits the total number of
internal error resets emitted by default before the connection is closed.
GitHub Security Advisory: GHSA-6r8p-hpg7-825g
Package: surrealdb (RUST)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-674: Uncontrolled Recursion
Vulnerable versions: < 1.1.0
Patched in: 1.1.0

Summary: Uncontrolled Recursion in SurrealQL Parsing

Details:
In some specific instances, the SurrealQL parser will attempt to recursively parse nested statements or idioms (i.e. nested `IF` and `RELATE` statements, nested basic idioms and nested access to attributes) without checking if the depth limit established by default or in the `SURREAL_MAX_COMPUTATION_DEPTH` environment variable is exceeded. This can lead to the stack overflowing when the nesting surpasses certain levels of depth.

### Impact

An attacker that is authorized to run queries on a SurrealDB server may be able to run a query using the affected statements and idioms with very deep nesting in order to crash the server, leading to denial of service.

### Patches

- Version 1.1.0 and later are not affected by this issue.

### Workarounds

Concerned users unable to update may want to limit the ability of untrusted users to run arbitrary SurrealQL queries in the affected versions of SurrealDB. To limit the impact of the denial of service, SurrealDB administrators may also want to ensure that the SurrealDB process is running so that it can be automatically re-started after a crash.

### References

- https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=62410
- https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=62652
- https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=63797
- https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=64445
- https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=64731
- https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=65277
GitHub Security Advisory: GHSA-m24x-r6q3-2vp9
Package: surrealdb (RUST)
Severity: HIGH (CVSS 7.5)
Vulnerable versions: < 1.1.0
Patched in: 1.1.0

Summary: Uncaught Exception processing HTTP Headers in SurrealDB

Details:
The `ID`, `DB` and `NS` headers accepted by the SurrealDB HTTP REST API would fail to parse when containing some special characters. This would cause a panic which would crash the SurrealDB server, leading to denial of service.

This issue only affects the SurrealDB binary; it does not affect the SurrealDB library.

### Impact

An unauthenticated client may issue an HTTP request to the SurrealDB HTTP REST API containing one of the affected headers with values containing special characters in order to crash the SurrealDB server. This does not require the SurrealDB server to be running with any specific capabilities other than exposing the affected interface.

### Patches

- Version 1.1.0 and later are not affected by this issue.

### Workarounds

Concerned users unable to update may want to limit untrusted access to the SurrealDB HTTP REST API unless such access is required by the application. To limit the impact of the denial of service, SurrealDB administrators may also want to ensure that the SurrealDB process is running so that it can be automatically re-started after a crash.

### References

- #2985 ([diff](https://github.com/surrealdb/surrealdb/pull/2985/files#diff-7ad06ddbb88d77138e5daf40a0dac5443d78947acd69a284a7c2bceb61f9c5f0L83-R119))
GitHub Security Advisory: GHSA-jm4v-58r5-66hj
Package: surrealdb (RUST)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-248: Uncaught Exception
Vulnerable versions: < 1.1.1
Patched in: 1.1.1

Summary: Uncaught Exception in surrealdb

Details:
Although custom parameters and functions are only supported at the database level, it was allowed to invoke those entities at the root or namespace level. This would cause a panic which would crash the SurrealDB server, leading to denial of service.

### Impact

A client that is authorized to run queries at the root or namespace level in a SurrealDB server is able to run a query invoking a parameter or a function at that level, which will cause a panic. This will crash the server, leading to denial of service.

### Patches

- Version 1.1.1 and later are not affected by this issue.

### Workarounds

Concerned users unable to update may want to limit the ability of untrusted users to run arbitrary SurrealQL queries in the affected versions of SurrealDB to the database level. To limit the impact of the denial of service, SurrealDB administrators may also want to ensure that the SurrealDB process is running so that it can be automatically re-started after a crash.

### References

- #3297
GitHub Security Advisory: GHSA-8f24-6m29-wm2r
Package: tracing (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-416: Use After Free
Vulnerable versions: >= 0.1.38, < 0.1.40
Patched in: 0.1.40

Summary: use-after-free in tracing 

Details:
The implementation of the [`Instrumented::into_inner`] method in affected versions of this crate contains undefined behavior due to incorrect use of [`std::mem::forget`] The function creates `*const` pointers to `self`, calls [`mem::forget(self)`][`std::mem::forget`], and then moves values out of those pointers using [`std::ptr::read`].

```rust
// To manually destructure `Instrumented` without `Drop`, we
// move it into a ManuallyDrop and use pointers to its fields
let span: *const Span = &this.span;
let inner: *const ManuallyDrop<T> = &this.inner;
mem::forget(self);
// SAFETY: Those pointers are valid for reads, because `Drop` didn't
//         run, and properly aligned, because `Instrumented` isn't
//         `#[repr(packed)]`.
let _span = unsafe { span.read() };
let inner = unsafe { inner.read() };
```

However, the [`mem::forget` documentation][`std::mem::forget`] states:

> Any resources the value manages, such as heap memory or a file handle, will
> linger forever in an unreachable state. **However, it does not guarantee that
> pointers to this memory will remain valid.**

This means that these pointers are no longer valid. This could result in a stack use-after-free if LLVM chooses to reuse `self`'s stack slot for a rebinding after the call to [`std::mem::forget`].

This undefined behavior has not been observed to cause miscompilation as of Rust 1.73.0. However, any use of this method with the affected versions of `tracing` are unsound.

The flaw was corrected in commit [20a1762] ([PR #2765]) by replacing the use of [`std::mem::forget`] with `std::mem::ManuallyDrop`, ensuring that the stack slot is not reused and the pointers remain valid when they are read. The fix is
published in `tracing` [v0.1.40]. Affected versions have been yanked from crates.io.

Thanks to [Taylor Cramer] and [Manish Goregaokar] for finding and correcting
this issue!

[`Instrumented::into_inner`]:
    https://docs.rs/tracing/latest/tracing/instrument/struct.Instrumented.html#method.into_inner
[`std::mem::forget`]: https://doc.rust-lang.org/std/mem/fn.forget.html
[`std::ptr::read`]:
    https://doc.rust-lang.org/std/primitive.pointer.html#method.read-1
[20a1762]:
    https://github.com/tokio-rs/tracing/commit/20a1762b3fd5f1fafead198fd18e469c68683721
[PR #2765]: https://github.com/tokio-rs/tracing/pull/2765
[v0.1.40]: https://crates.io/crates/tracing/0.1.40
[Taylor Cramer]: https://github.com/cramertj
[Manish Goregaokar]: https://github.com/manishearth
GitHub Security Advisory: GHSA-v363-rrf2-5fmj
Package: ferris-says (RUST)
Severity: LOW (CVSS 0.0)
Vulnerable versions: >= 0.3.0, < 0.3.1
Patched in: 0.3.1

Summary: ferris-says has undefined behavior when not using UTF-8

Details:
Affected versions receive a `&[u8]` from the caller through a safe API, and pass it directly to the unsafe `str::from_utf8_unchecked` function.

The behavior of `ferris_says::say` is undefined if the bytes from the caller don't happen to be valid UTF-8.

The flaw was corrected in [ferris-says#21] by using the safe `str::from_utf8` instead, and returning an error on invalid input. However this fix has not yet been published to crates.io as a patch version for 0.2.

Separately, [ferris-says#32] has introduced a different API for version 0.3 which accepts input as `&str` rather than `&[u8]`, so is unaffected by this bug.

[ferris-says#21]: https://github.com/rust-lang/ferris-says/pull/21
[ferris-says#32]: https://github.com/rust-lang/ferris-says/pull/32
GitHub Security Advisory: GHSA-v363-rrf2-5fmj
Package: ferris-says (RUST)
Severity: LOW (CVSS 0.0)
Vulnerable versions: >= 0.1.2, <= 0.2.1
Patched in: unpatched

Summary: ferris-says has undefined behavior when not using UTF-8

Details:
Affected versions receive a `&[u8]` from the caller through a safe API, and pass it directly to the unsafe `str::from_utf8_unchecked` function.

The behavior of `ferris_says::say` is undefined if the bytes from the caller don't happen to be valid UTF-8.

The flaw was corrected in [ferris-says#21] by using the safe `str::from_utf8` instead, and returning an error on invalid input. However this fix has not yet been published to crates.io as a patch version for 0.2.

Separately, [ferris-says#32] has introduced a different API for version 0.3 which accepts input as `&str` rather than `&[u8]`, so is unaffected by this bug.

[ferris-says#21]: https://github.com/rust-lang/ferris-says/pull/21
[ferris-says#32]: https://github.com/rust-lang/ferris-says/pull/32
GitHub Security Advisory: GHSA-6698-mhxx-r84g
Package: anoncreds-clsignatures (RUST)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-327: Use of a Broken or Risky Cryptographic Algorithm
Vulnerable versions: < 0.1.0
Patched in: 0.1.0

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].