deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-4q83-7cq4-p6wg
Package: tokio (RUST)
Severity: LOW (CVSS 0.0)
Vulnerable versions: >= 0.2.0, < 1.18.5
Patched in: 1.18.5

Summary: `tokio::io::ReadHalf<T>::unsplit` is Unsound

Details:
`tokio::io::ReadHalf<T>::unsplit` can violate the `Pin` contract

The soundness issue is described in the [tokio/issues#5372](https://github.com/tokio-rs/tokio/issues/5372)

Specific set of conditions needed to trigger an issue (a !Unpin type in ReadHalf)
is unusual, combined with the difficulty of making any arbitrary use-after-free
exploitable in Rust without doing a lot of careful alignment of data types in
the surrounding code.

The `tokio` feature `io-util` is also required to be enabled to trigger this
soundness issue.

Thanks to zachs18 reporting the issue to Tokio team responsibly and taiki-e
and carllerche appropriately responding and fixing the soundness bug.

Tokio before 0.2.0 used `futures` 0.1 that did not have `Pin`, so it is not
affected by this issue.
GitHub Security Advisory: GHSA-4q83-7cq4-p6wg
Package: tokio (RUST)
Severity: LOW (CVSS 0.0)
Vulnerable versions: >= 1.19.0, < 1.20.4
Patched in: 1.20.4

Summary: `tokio::io::ReadHalf<T>::unsplit` is Unsound

Details:
`tokio::io::ReadHalf<T>::unsplit` can violate the `Pin` contract

The soundness issue is described in the [tokio/issues#5372](https://github.com/tokio-rs/tokio/issues/5372)

Specific set of conditions needed to trigger an issue (a !Unpin type in ReadHalf)
is unusual, combined with the difficulty of making any arbitrary use-after-free
exploitable in Rust without doing a lot of careful alignment of data types in
the surrounding code.

The `tokio` feature `io-util` is also required to be enabled to trigger this
soundness issue.

Thanks to zachs18 reporting the issue to Tokio team responsibly and taiki-e
and carllerche appropriately responding and fixing the soundness bug.

Tokio before 0.2.0 used `futures` 0.1 that did not have `Pin`, so it is not
affected by this issue.
GitHub Security Advisory: GHSA-4q83-7cq4-p6wg
Package: tokio (RUST)
Severity: LOW (CVSS 0.0)
Vulnerable versions: >= 1.21.0, < 1.24.2
Patched in: 1.24.2

Summary: `tokio::io::ReadHalf<T>::unsplit` is Unsound

Details:
`tokio::io::ReadHalf<T>::unsplit` can violate the `Pin` contract

The soundness issue is described in the [tokio/issues#5372](https://github.com/tokio-rs/tokio/issues/5372)

Specific set of conditions needed to trigger an issue (a !Unpin type in ReadHalf)
is unusual, combined with the difficulty of making any arbitrary use-after-free
exploitable in Rust without doing a lot of careful alignment of data types in
the surrounding code.

The `tokio` feature `io-util` is also required to be enabled to trigger this
soundness issue.

Thanks to zachs18 reporting the issue to Tokio team responsibly and taiki-e
and carllerche appropriately responding and fixing the soundness bug.

Tokio before 0.2.0 used `futures` 0.1 that did not have `Pin`, so it is not
affected by this issue.
GitHub Security Advisory: GHSA-8v4j-7jgf-5rg9
Package: warp (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 0.3.3
Patched in: 0.3.3

Summary: Warp vulnerable to Path Traversal via Improper validation of Windows paths

Details:
Path resolution in `warp::filters::fs::dir` didn't correctly validate Windows paths meaning paths like `/foo/bar/c:/windows/web/screen/img101.png` would be allowed and respond with the contents of `c:/windows/web/screen/img101.png`. Thus users could potentially read files anywhere on the filesystem.

This only impacts Windows. Linux and other unix likes are not impacted by this.
GitHub Security Advisory: GHSA-w9r2-qrpm-4rmj
Package: disrustor (RUST)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Vulnerable versions: < 0.3.0
Patched in: 0.3.0

Summary: Data race in disrustor

Details:
An issue was discovered in the disrustor crate through 2020-12-17 for Rust. RingBuffer doe not properly limit the number of mutable references.
GitHub Security Advisory: GHSA-pfjq-935c-4895
Package: v9 (RUST)
Severity: HIGH (CVSS 8.1)
CWE: CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Vulnerable versions: < 0.1.43
Patched in: 0.1.43

Summary: Data races in v9

Details:
Affected versions of this crate unconditionally implement `Sync` for `SyncRef<T>`. This definition allows data races if `&T` is accessible through `&SyncRef`.

`SyncRef<T>` derives `Clone` and `Debug`, and the default implementations of those traits access `&T` by invoking `T::clone()` & `T::fmt()`. It is possible to create data races & undefined behavior by concurrently invoking `SyncRef<T>::clone()` or `SyncRef<T>::fmt()` from multiple threads with `T: !Sync`.
GitHub Security Advisory: GHSA-m4ch-rfv5-x5g3
Package: git2 (RUST)
Severity: MODERATE (CVSS 6.8)
Vulnerable versions: < 0.16.1
Patched in: 0.16.1

Summary: git2-rs fails to verify SSH keys by default

Details:
The git2 and libgit2-sys crates are Rust wrappers around the [libgit2](https://libgit2.org/) C library. It was discovered that libgit2 1.5.0 and below did not verify SSH host keys when establishing an SSH connection, exposing users of the library to Man-In-the-Middle attacks.

The libgit2 team assigned [CVE-2023-22742](https://github.com/libgit2/libgit2/security/advisories/GHSA-8643-3wh5-rmjq) to this vulnerability. The following versions of the libgit2-sys Rust crate have been released:

* libgit2-sys 0.14.2, updating the underlying libgit2 C library to version 1.5.1.
* libgit2-sys 0.13.5, updating the underlying libgit2 C library to version 1.4.5.

A new git2 crate version has also been released, 0.16.1. This version only bumps its libgit2-sys dependency to ensure no vulnerable libgit2-sys versions are used, but contains no code changes: if you update the libgit2-sys version there is no need to also update the git2 crate version.

[You can learn more about this vulnerability in libgit2's advisory](https://github.com/libgit2/libgit2/security/advisories/GHSA-8643-3wh5-rmjq)
GitHub Security Advisory: GHSA-m4ch-rfv5-x5g3
Package: libgit2-sys (RUST)
Severity: MODERATE (CVSS 6.8)
Vulnerable versions: < 0.13.5
Patched in: 0.13.5

Summary: git2-rs fails to verify SSH keys by default

Details:
The git2 and libgit2-sys crates are Rust wrappers around the [libgit2](https://libgit2.org/) C library. It was discovered that libgit2 1.5.0 and below did not verify SSH host keys when establishing an SSH connection, exposing users of the library to Man-In-the-Middle attacks.

The libgit2 team assigned [CVE-2023-22742](https://github.com/libgit2/libgit2/security/advisories/GHSA-8643-3wh5-rmjq) to this vulnerability. The following versions of the libgit2-sys Rust crate have been released:

* libgit2-sys 0.14.2, updating the underlying libgit2 C library to version 1.5.1.
* libgit2-sys 0.13.5, updating the underlying libgit2 C library to version 1.4.5.

A new git2 crate version has also been released, 0.16.1. This version only bumps its libgit2-sys dependency to ensure no vulnerable libgit2-sys versions are used, but contains no code changes: if you update the libgit2-sys version there is no need to also update the git2 crate version.

[You can learn more about this vulnerability in libgit2's advisory](https://github.com/libgit2/libgit2/security/advisories/GHSA-8643-3wh5-rmjq)
GitHub Security Advisory: GHSA-m4ch-rfv5-x5g3
Package: libgit2-sys (RUST)
Severity: MODERATE (CVSS 6.8)
Vulnerable versions: >= 0.14.0, < 0.14.2
Patched in: 0.14.2

Summary: git2-rs fails to verify SSH keys by default

Details:
The git2 and libgit2-sys crates are Rust wrappers around the [libgit2](https://libgit2.org/) C library. It was discovered that libgit2 1.5.0 and below did not verify SSH host keys when establishing an SSH connection, exposing users of the library to Man-In-the-Middle attacks.

The libgit2 team assigned [CVE-2023-22742](https://github.com/libgit2/libgit2/security/advisories/GHSA-8643-3wh5-rmjq) to this vulnerability. The following versions of the libgit2-sys Rust crate have been released:

* libgit2-sys 0.14.2, updating the underlying libgit2 C library to version 1.5.1.
* libgit2-sys 0.13.5, updating the underlying libgit2 C library to version 1.4.5.

A new git2 crate version has also been released, 0.16.1. This version only bumps its libgit2-sys dependency to ensure no vulnerable libgit2-sys versions are used, but contains no code changes: if you update the libgit2-sys version there is no need to also update the git2 crate version.

[You can learn more about this vulnerability in libgit2's advisory](https://github.com/libgit2/libgit2/security/advisories/GHSA-8643-3wh5-rmjq)
GitHub Security Advisory: GHSA-g6pw-999w-j75m
Package: elf_rs (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: < 0.3.0
Patched in: 0.3.0

Summary: ELF header parsing library doesn't check for valid offset

Details:
The crate has several unsafe sections that don't perform proper pointer validation.

An example can be found in the following function:

```
fn section_header_raw(&self) -> &[ET::SectionHeader] {
    let sh_off = self.elf_header().section_header_offset() as usize;
    let sh_num = self.elf_header().section_header_entry_num() as usize;
    unsafe {
        let sh_ptr = self.content().as_ptr().add(sh_off);
        from_raw_parts(sh_ptr as *const ET::SectionHeader, sh_num)
    }
}
```

While this will work perfectly fine *if* the ELF header is valid, malicious or malformed input can contain a section header offset of an arbitrary size, meaning that the resultant pointer in the unsafe block can point to an artibrary address in the address space of the process.

This can result in unpredictable behaviour, and in our fuzz testing, we discovered that it's trivial to cause SIGABRT (signal 6), or SEGV (signal 11).

The function should either be marked as unsafe, with a note that the caller is responsible for providing only valid inputs, or it should ideally do the due diligence to ensure that the offset doesn't exceed the bounds of the header (and add additional checks as necessary).
GitHub Security Advisory: GHSA-f85w-wvc7-crwc
Package: bumpalo (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 1.1.0, < 3.11.1
Patched in: 3.11.1

Summary: bumpalo has use-after-free due to a lifetime error in `Vec::into_iter()`

Details:
In affected versions of this crate, the lifetime of the iterator produced by `Vec::into_iter()` is not constrained to the lifetime of the `Bump` that allocated the vector's memory. Using the iterator after the `Bump` is dropped causes use-after-free accesses.

The following example demonstrates memory corruption arising from a misuse of this unsoundness.

```rust
use bumpalo::{collections::Vec, Bump};

fn main() {
    let bump = Bump::new();
    let mut vec = Vec::new_in(&bump);
    vec.extend([0x01u8; 32]);
    let into_iter = vec.into_iter();
    drop(bump);

    for _ in 0..100 {
        let reuse_bump = Bump::new();
        let _reuse_alloc = reuse_bump.alloc([0x41u8; 10]);
    }

    for x in into_iter {
        print!("0x{:02x} ", x);
    }
    println!();
}
```

The issue was corrected in version 3.11.1 by adding a lifetime to the `IntoIter` type, and updating the signature of `Vec::into_iter()` to constrain this lifetime.
GitHub Security Advisory: GHSA-3837-87vh-xq3w
Package: v9 (RUST)
Severity: HIGH (CVSS 8.1)
CWE: CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')
Vulnerable versions: < 0.1.43
Patched in: 0.1.43

Summary: Data race in v9

Details:
Affected versions of this crate unconditionally implement Sync for SyncRef<T>. This definition allows data races if &T is accessible through &SyncRef.

SyncRef<T> derives Clone and Debug, and the default implementations of those traits access &T by invoking T::clone() & T::fmt(). It is possible to create data races & undefined behavior by concurrently invoking SyncRef<T>::clone() or SyncRef<T>::fmt() from multiple threads with T: !Sync.
GitHub Security Advisory: GHSA-m589-mv4q-p7rj
Package: webbrowser (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 0.8.3
Patched in: 0.8.3

Summary: webbrowser-rs allows attackers to access arbitrary files via supplying a crafted URL

Details:
An issue in the IpFile argument of rust-lang webbrowser-rs v0.8.2 allows attackers to access arbitrary files via supplying a crafted URL.
GitHub Security Advisory: GHSA-96jv-r488-c2rj
Package: bzip2 (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-190: Integer Overflow or Wraparound
Vulnerable versions: < 0.4.4
Patched in: 0.4.4

Summary: bzip2 allows attackers to cause a denial of service via a large file that triggers an integer overflow

Details:
The bzip2 crate before 0.4.4 for Rust allow attackers to cause a denial of service via a large file that triggers an integer overflow in `mem.rs`. NOTE: this is unrelated to the https://crates.io/crates/bzip2-rs product.
GitHub Security Advisory: GHSA-7rrj-xr53-82p7
Package: tokio (RUST)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-665: Improper Initialization
Vulnerable versions: >= 1.21.0, < 1.23.1
Patched in: 1.23.1

Summary: Tokio reject_remote_clients configuration may get dropped when creating a Windows named pipe

Details:
### Impact

When configuring a Windows named pipe server, setting `pipe_mode` will reset `reject_remote_clients` to `false`. If the application has previously configured `reject_remote_clients` to `true`, this effectively undoes the configuration. This also applies if `reject_remote_clients` is not explicitly set as this is the default configuration and is cleared by calling `pipe_mode`.

Remote clients may only access the named pipe if the named pipe's associated path is accessible via a publically shared folder (SMB).

### Patches

The following versions have been patched:
* 1.23.1
* 1.20.3
* 1.18.4

The fix will also be present in all releases starting from version 1.24.0.

Named pipes were introduced to Tokio in version 1.7.0, so releases older than 1.7.0 are not affected.

### Workarounds

Ensure that `pipe_mode` is set **first** after initializing a `ServerOptions`. For example:

```rust
let mut opts = ServerOptions::new();
opts.pipe_mode(PipeMode::Message);
opts.reject_remote_clients(true);
```

### References

https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-createnamedpipea#pipe_reject_remote_clients
GitHub Security Advisory: GHSA-7rrj-xr53-82p7
Package: tokio (RUST)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-665: Improper Initialization
Vulnerable versions: >= 1.19.0, < 1.20.3
Patched in: 1.20.3

Summary: Tokio reject_remote_clients configuration may get dropped when creating a Windows named pipe

Details:
### Impact

When configuring a Windows named pipe server, setting `pipe_mode` will reset `reject_remote_clients` to `false`. If the application has previously configured `reject_remote_clients` to `true`, this effectively undoes the configuration. This also applies if `reject_remote_clients` is not explicitly set as this is the default configuration and is cleared by calling `pipe_mode`.

Remote clients may only access the named pipe if the named pipe's associated path is accessible via a publically shared folder (SMB).

### Patches

The following versions have been patched:
* 1.23.1
* 1.20.3
* 1.18.4

The fix will also be present in all releases starting from version 1.24.0.

Named pipes were introduced to Tokio in version 1.7.0, so releases older than 1.7.0 are not affected.

### Workarounds

Ensure that `pipe_mode` is set **first** after initializing a `ServerOptions`. For example:

```rust
let mut opts = ServerOptions::new();
opts.pipe_mode(PipeMode::Message);
opts.reject_remote_clients(true);
```

### References

https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-createnamedpipea#pipe_reject_remote_clients
GitHub Security Advisory: GHSA-7rrj-xr53-82p7
Package: tokio (RUST)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-665: Improper Initialization
Vulnerable versions: >= 1.7.0, < 1.18.4
Patched in: 1.18.4

Summary: Tokio reject_remote_clients configuration may get dropped when creating a Windows named pipe

Details:
### Impact

When configuring a Windows named pipe server, setting `pipe_mode` will reset `reject_remote_clients` to `false`. If the application has previously configured `reject_remote_clients` to `true`, this effectively undoes the configuration. This also applies if `reject_remote_clients` is not explicitly set as this is the default configuration and is cleared by calling `pipe_mode`.

Remote clients may only access the named pipe if the named pipe's associated path is accessible via a publically shared folder (SMB).

### Patches

The following versions have been patched:
* 1.23.1
* 1.20.3
* 1.18.4

The fix will also be present in all releases starting from version 1.24.0.

Named pipes were introduced to Tokio in version 1.7.0, so releases older than 1.7.0 are not affected.

### Workarounds

Ensure that `pipe_mode` is set **first** after initializing a `ServerOptions`. For example:

```rust
let mut opts = ServerOptions::new();
opts.pipe_mode(PipeMode::Message);
opts.reject_remote_clients(true);
```

### References

https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-createnamedpipea#pipe_reject_remote_clients
GitHub Security Advisory: GHSA-r3r5-jhw6-4634
Package: Simple-Wayland-HotKey-Daemon (RUST)
Severity: CRITICAL (CVSS 9.1)
CWE: CWE-668: Exposure of Resource to Wrong Sphere
Vulnerable versions: < 1.2.0
Patched in: 1.2.0

Summary: Insecure temporary file usage in SWHKD

Details:
SWHKD 1.1.5 unsafely uses the /tmp/swhkd.sock pathname. There can be an information leak or denial of service.
GitHub Security Advisory: GHSA-gfgm-chr3-x6px
Package: prettytable-rs (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: < 0.10.0
Patched in: 0.10.0

Summary: prettytable-rs: Force cast a &Vec<T> to &[T] may lead to undefined behavior

Details:
In function `Table::as_ref`, a reference of vector is force cast to slice. There are multiple problems here:
1. To guarantee the size is correct, we have to first do `Vec::shrink_to_fit`. The function requires a mutable reference, so we have to force cast from immutable to mutable, which is undefined behavior (UB).
2. Even if (1) is sound, `&Vec<T>` and `&[T]` still might not have the same layout. Treating them equally may lead to undefinted behavior (UB).
GitHub Security Advisory: GHSA-5wvv-q5fv-2388
Package: hyper-staticfile (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
Vulnerable versions: >= 0.10.0-alpha.1, < 0.10.0-alpha.5
Patched in: 0.10.0-alpha.5

Summary: hyper-staticfile's location header incorporates user input, allowing open redirect

Details:
When `hyper-staticfile` performs a redirect for a directory request (e.g. a request for `/dir` that redirects to `/dir/`), the `Location` header value was derived from user input (the request path), simply appending a slash. The intent was to perform an origin-relative redirect, but specific inputs allowed performing a scheme-relative redirect instead.

An attacker could craft a special URL that would appear to be for the correct domain, but immediately redirects to a malicious domain. Such a URL can benefit phishing attacks, for example an innocent looking link in an email.
GitHub Security Advisory: GHSA-5wvv-q5fv-2388
Package: hyper-staticfile (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
Vulnerable versions: < 0.9.4
Patched in: 0.9.4

Summary: hyper-staticfile's location header incorporates user input, allowing open redirect

Details:
When `hyper-staticfile` performs a redirect for a directory request (e.g. a request for `/dir` that redirects to `/dir/`), the `Location` header value was derived from user input (the request path), simply appending a slash. The intent was to perform an origin-relative redirect, but specific inputs allowed performing a scheme-relative redirect instead.

An attacker could craft a special URL that would appear to be for the correct domain, but immediately redirects to a malicious domain. Such a URL can benefit phishing attacks, for example an innocent looking link in an email.
GitHub Security Advisory: GHSA-xqqc-c5gw-c5r5
Package: tendermint-light-client-js (RUST)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: <= 0.27.0
Patched in: 0.28.0

Summary: Tendermint light client verification not taking into account chain ID

Details:
### Impact

Anyone using the `tendermint-light-client` and related packages to perform light client verification (e.g. IBC-rs, Hermes).

At present, the light client does not check that the chain IDs of the trusted and untrusted headers match, resulting in a possible attack vector where someone who finds a header from an untrusted chain that satisfies all other verification conditions (e.g. enough overlapping validator signatures) could fool a light client.

The attack vector is currently theoretical, and no proof-of-concept exists yet to exploit it on live networks.

### Patches

Users of the light client-related crates can currently upgrade to `v0.28.0`.

### Workarounds

None

### References

- [Light Client specification](https://github.com/tendermint/tendermint/tree/main/spec/light-client)
GitHub Security Advisory: GHSA-xqqc-c5gw-c5r5
Package: tendermint-light-client (RUST)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: <= 0.27.0
Patched in: 0.28.0

Summary: Tendermint light client verification not taking into account chain ID

Details:
### Impact

Anyone using the `tendermint-light-client` and related packages to perform light client verification (e.g. IBC-rs, Hermes).

At present, the light client does not check that the chain IDs of the trusted and untrusted headers match, resulting in a possible attack vector where someone who finds a header from an untrusted chain that satisfies all other verification conditions (e.g. enough overlapping validator signatures) could fool a light client.

The attack vector is currently theoretical, and no proof-of-concept exists yet to exploit it on live networks.

### Patches

Users of the light client-related crates can currently upgrade to `v0.28.0`.

### Workarounds

None

### References

- [Light Client specification](https://github.com/tendermint/tendermint/tree/main/spec/light-client)
GitHub Security Advisory: GHSA-xqqc-c5gw-c5r5
Package: tendermint-light-client-verifier (RUST)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: <= 0.27.0
Patched in: 0.28.0

Summary: Tendermint light client verification not taking into account chain ID

Details:
### Impact

Anyone using the `tendermint-light-client` and related packages to perform light client verification (e.g. IBC-rs, Hermes).

At present, the light client does not check that the chain IDs of the trusted and untrusted headers match, resulting in a possible attack vector where someone who finds a header from an untrusted chain that satisfies all other verification conditions (e.g. enough overlapping validator signatures) could fool a light client.

The attack vector is currently theoretical, and no proof-of-concept exists yet to exploit it on live networks.

### Patches

Users of the light client-related crates can currently upgrade to `v0.28.0`.

### Workarounds

None

### References

- [Light Client specification](https://github.com/tendermint/tendermint/tree/main/spec/light-client)