deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-2hvr-h6gw-qrxp
Package: cargo (RUST)
Severity: MODERATE (CVSS 4.2)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: = 0.66.0
Patched in: 0.67.0

Summary: Cargo extracting malicious crates can fill the file system

Details:
The Rust Security Response WG was notified that Cargo did not prevent extracting some malformed packages downloaded from alternate registries. An attacker able to upload packages to an alternate registry could fill the file system when Cargo downloaded the package.

The severity of this vulnerability is "low" for users of alternate registries. Users relying on crates.io are not affected.

Note that **by design** Cargo allows code execution at build time, due to build scripts and procedural macros. The vulnerabilities in this advisory allow performing a subset of the possible damage in a harder to track down way. Your dependencies must still be trusted if you want to be protected from attacks, as it's possible to perform the same attacks with build scripts and procedural macros.

## Disk space exaustion

It was discovered that Cargo did not limit the amount of data extracted from compressed archives. An attacker could upload to an alternate registry a specially crafted package that extracts way more data than its size (also known as a "zip bomb"), exhausting the disk space on the machine using Cargo to download the package.

## Affected versions

The vulnerability is present in all versions of Cargo. Rust 1.64, to be released on September 22nd, will include a fix for it.

Since the vulnerability is just a more limited way to accomplish what a malicious build scripts or procedural macros can do, we decided not to publish Rust point releases backporting the security fix. Patch files are available for Rust 1.63.0 are available [in the wg-security-response repository][patches] for people building their own toolchain.

## Mitigations

We recommend users of alternate registries to excercise care in which package they download, by only including trusted dependencies in their projects. Please note that even with these vulnerabilities fixed, by design Cargo allows arbitrary code execution at build time thanks to build scripts and procedural macros: a malicious dependency will be able to cause damage regardless of these vulnerabilities.

crates.io implemented server-side checks to reject these kinds of packages years ago, and there are no packages on crates.io exploiting these vulnerabilities. crates.io users still need to excercise care in choosing their dependencies though, as the same concerns about build scripts and procedural macros apply here.

## Acknowledgements

We want to thank Ori Hollander from JFrog Security Research for responsibly disclosing this to us according to the [Rust security policy][policy].

We also want to thank Josh Triplett for developing the fixes, Weihang Lo for developing the tests, and Pietro Albini for writing this advisory. The disclosure was coordinated by Pietro Albini and Josh Stone.

[policy]: https://www.rust-lang.org/policies/security
[patches]: https://github.com/rust-lang/wg-security-response/tree/master/patches
GitHub Security Advisory: GHSA-2hvr-h6gw-qrxp
Package: cargo (RUST)
Severity: MODERATE (CVSS 4.2)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: < 0.65.0
Patched in: 0.65.0

Summary: Cargo extracting malicious crates can fill the file system

Details:
The Rust Security Response WG was notified that Cargo did not prevent extracting some malformed packages downloaded from alternate registries. An attacker able to upload packages to an alternate registry could fill the file system when Cargo downloaded the package.

The severity of this vulnerability is "low" for users of alternate registries. Users relying on crates.io are not affected.

Note that **by design** Cargo allows code execution at build time, due to build scripts and procedural macros. The vulnerabilities in this advisory allow performing a subset of the possible damage in a harder to track down way. Your dependencies must still be trusted if you want to be protected from attacks, as it's possible to perform the same attacks with build scripts and procedural macros.

## Disk space exaustion

It was discovered that Cargo did not limit the amount of data extracted from compressed archives. An attacker could upload to an alternate registry a specially crafted package that extracts way more data than its size (also known as a "zip bomb"), exhausting the disk space on the machine using Cargo to download the package.

## Affected versions

The vulnerability is present in all versions of Cargo. Rust 1.64, to be released on September 22nd, will include a fix for it.

Since the vulnerability is just a more limited way to accomplish what a malicious build scripts or procedural macros can do, we decided not to publish Rust point releases backporting the security fix. Patch files are available for Rust 1.63.0 are available [in the wg-security-response repository][patches] for people building their own toolchain.

## Mitigations

We recommend users of alternate registries to excercise care in which package they download, by only including trusted dependencies in their projects. Please note that even with these vulnerabilities fixed, by design Cargo allows arbitrary code execution at build time thanks to build scripts and procedural macros: a malicious dependency will be able to cause damage regardless of these vulnerabilities.

crates.io implemented server-side checks to reject these kinds of packages years ago, and there are no packages on crates.io exploiting these vulnerabilities. crates.io users still need to excercise care in choosing their dependencies though, as the same concerns about build scripts and procedural macros apply here.

## Acknowledgements

We want to thank Ori Hollander from JFrog Security Research for responsibly disclosing this to us according to the [Rust security policy][policy].

We also want to thank Josh Triplett for developing the fixes, Weihang Lo for developing the tests, and Pietro Albini for writing this advisory. The disclosure was coordinated by Pietro Albini and Josh Stone.

[policy]: https://www.rust-lang.org/policies/security
[patches]: https://github.com/rust-lang/wg-security-response/tree/master/patches
GitHub Security Advisory: GHSA-j984-q4qc-6qxf
Package: librsvg (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: < 2.40.12
Patched in: 2.40.12

Summary: librsvg DoS via Cyclic References

Details:
librsvg before 2.40.12 allows context-dependent attackers to cause a denial of service (infinite loop, stack consumption, and application crash) via cyclic references in an SVG document.
GitHub Security Advisory: GHSA-c3x7-354f-4p2x
Package: lol-html (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: < 1.1.1
Patched in: 1.1.1

Summary: lol-html panics on certain HTML inputs

Details:
### Impact
lol-html can cause panics on certain HTML inputs. Anyone processing arbitrary 3rd party HTML with the library is affected.

### Patches
The problem has been patched and released as v1.1.1

### Workarounds
No workarounds exist.
GitHub Security Advisory: GHSA-gpcv-p28p-fv2p
Package: odoh-rs (RUST)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
Vulnerable versions: < 1.0.2
Patched in: 1.0.2

Summary: odoh-rs's Invalid Slice Split Results in Server Panic

Details:
A vulnerability was discovered in the odoh-rs rust crate that stems from faulty logic during the parsing of encrypted queries. This issue specifically occurs when processing encrypted query data received from remote clients.

### Impact
An attacker with knowledge of this vulnerability could craft and send specially designed encrypted queries to targeted ODOH servers running with odoh-rs. Upon successful exploitation, the server will crash abruptly, disrupting its normal operation and rendering the service temporarily unavailable.

### Patches
Users are encouraged to update their odoh-rs's rust crate to v1.0.2.
GitHub Security Advisory: GHSA-779w-xvpm-78jx
Package: twitch-tui (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-311: Missing Encryption of Sensitive Data
Vulnerable versions: < 2.4.1
Patched in: 2.4.1

Summary: twitch-tui's connection is not encrypted

Details:
### Summary
The connection is not using TLS for communication

### Details
In the configuration of the irc connection, [you are disabling tls](https://github.com/Xithrius/twitch-tui/blob/340afc3c8c07a83289fe6ef614aa7563c8b70756/src/twitch/connection.rs#L23) which makes all communication to twitch irc servers unencrypted.

### PoC
You can verify by using tcpdump/wireshark that traffic is unencrypted.

### Impact
Communication can be sniffed, even auth tokens.
GitHub Security Advisory: GHSA-gch5-hwqf-mxhp
Package: intaglio (RUST)
Severity: LOW (CVSS 0.0)
Vulnerable versions: < 1.9.0
Patched in: 1.9.0

Summary: Unsoundness in `intern` methods on `intaglio` symbol interners

Details:
Affected versions of this crate have a stacked borrows violation when creating
references to interned contents. All interner types are affected.

The flaw was corrected in version 1.9.0 by reordering move and borrowing
operations and storing interned contents by raw pointer instead of as a `Box`.
GitHub Security Advisory: GHSA-rfhg-rjfp-9q8q
Package: s2n-quic (RUST)
Severity: LOW (CVSS 0.0)
Vulnerable versions: <= 1.24.0
Patched in: 1.25.0

Summary: Potential denial of service after connection migration

Details:
### Impact
An issue in s2n-quic results in the endpoint shutting down due to a combination of peer-initiated connection migration and duplicate new connection ID frames being received. No AWS services are affected by this issue, and customers of AWS services do not need to take action.

Impacted versions: <=v1.24.0
### Patches
The patch is included in v1.25.0.

### Workarounds
There is no workaround. Applications using s2n-quic should upgrade their application to the most recent release of s2n-quic.

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.
GitHub Security Advisory: GHSA-f2wx-xjfw-xjv6
Package: topgrade (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition
Vulnerable versions: <= 12.0.0
Patched in: 12.0.1

Summary: topgrade Time-of-check Time-of-use (TOCTOU) Race Condition in remove_dir_all

Details:
### Summary
https://github.com/advisories/GHSA-mc8h-8q98-g5hr
https://github.com/XAMPPRocky/remove_dir_all/commit/7247a8b6ee59fc99bbb69ca6b3ca4bfd8c809ead

`tempfile` v0.4.26 ships with affected `remove_dir_all` v0.5.3 and so blocks my deployment of v12 to openSUSE distribution because it imposes a clean `cargo audit`

Updating `tempfile` is warranted
GitHub Security Advisory: GHSA-f9g6-fp84-fv92
Package: lmdb-rs (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: <= 0.7.6
Patched in: unpatched

Summary: impl `FromMdbValue` for bool is unsound

Details:
The implementation of `FromMdbValue` has several unsoundness issues. First of all, it allows to reinterpret arbitrary bytes as a bool and could make undefined behavior happen with safe function. Secondly, it allows transmuting pointer without taking memory layout into consideration. The details of reproducing the bug are available [here](https://github.com/vhbit/lmdb-rs/issues/67).
GitHub Security Advisory: GHSA-m3x9-623g-35c4
Package: routinator (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-674: Uncontrolled Recursion, CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop')
Vulnerable versions: < 0.10.2
Patched in: 0.10.2

Summary: Routinator infinite loop vulnerability

Details:
NLnet Labs Routinator prior to 0.10.2 happily processes a chain of RRDP repositories of infinite length causing it to never finish a validation run. In RPKI, a CA can choose the RRDP repository it wishes to publish its data in. By continuously generating a new child CA that only consists of another CA using a different RRDP repository, a malicious CA can create a chain of CAs of de-facto infinite length. Routinator prior to version 0.10.2 did not contain a limit on the length of such a chain and will therefore continue to process this chain forever. As a result, the validation run will never finish, leading to Routinator continuing to serve the old data set or, if in the initial validation run directly after starting, never serve any data at all.
GitHub Security Advisory: GHSA-3288-cwgw-ch86
Package: xcb (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-252: Unchecked Return Value
Vulnerable versions: < 1.0.0
Patched in: 1.0.0

Summary: Unchecked Return Value in xcb

Details:
An issue was discovered in the xcb crate through 2021-02-04 for Rust. It has a soundness violation because xcb::xproto::GetAtomNameReply::name() calls std::str::from_utf8_unchecked() on unvalidated bytes from an X server.
GitHub Security Advisory: GHSA-hxq4-mx37-fqvg
Package: s2n-quic (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: = 1.22.0
Patched in: 1.23.0

Summary: s2n-quic potential denial of service vulnerability when receiving empty UDP packets

Details:
### Impact

An issue in s2n-quic results in the endpoint shutting down after receiving an empty UDP packet on a connection. 

No AWS services are affected by this issue and customers of AWS services do not need to take action. Applications using s2n-quic should upgrade their application to the most recent release of s2n-quic.

Impacted version: s2n-quic v1.22.0.

### Patches

The patch is included in s2n-quic [v1.23.0](https://github.com/aws/s2n-quic/releases/tag/v1.23.0).

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our [vulnerability reporting page](https://aws.amazon.com/security/vulnerability-reporting) or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.
GitHub Security Advisory: GHSA-g753-ghr7-q33w
Package: cyfs-base (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: <= 0.6.12
Patched in: unpatched

Summary: cyfs-base vulnerable to misaligned pointer dereference in `ChunkId::new`

Details:
The function `ChunkId::new` creates a misaligned pointer by casting mutable pointer of `u8` slice which has alignment 1 to the mutable pointer of `u32` which has alignment 4, and dereference the misaligned pointer leading UB, which should not be allowed in safe function.
GitHub Security Advisory: GHSA-gwc9-348x-qwv2
Package: wasmtime (RUST)
Severity: HIGH (CVSS 8.1)
CWE: CWE-416: Use After Free
Vulnerable versions: >= 0.35.0, < 0.35.2
Patched in: 0.35.2

Summary: Use after free in Wasmtime

Details:
There is a use after free vulnerability in Wasmtime when both running Wasm that uses `externref`s and enabling [epoch interruption](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.epoch_interruption) in Wasmtime. If you are not explicitly enabling epoch interruption (it is disabled by default) then you are not affected. If you are explicitly disabling the Wasm reference types proposal (it is enabled by default) then you are also not affected.

The use after free is caused by Cranelift failing to emit stack maps when there are safepoints inside cold blocks. Cold blocks occur when epoch interruption is enabled. Cold blocks are emitted at the end of compiled functions, and change the order blocks are emitted versus defined. This reordering accidentally caused Cranelift to skip emitting some stack maps because it expected to emit the stack maps in block definition order, rather than block emission order. When Wasmtime would eventually collect garbage, it would fail to find live references on the stack because of the missing stack maps, think that they were unreferenced garbage, and therefore reclaim them. Then after the collection ended, the Wasm code could use the reclaimed-too-early references, which is a use after free.

This bug was discovered while extending our fuzz targets for `externref`s and GC in Wasmtime. The updated fuzz target thoroughly exercises these code paths and feature combinations now. We have also added a regression test for this bug. Released versions 0.34.2 and 0.35.2, which fix the vulnerability. We recommend all Wasmtime users upgrade to these patched versions. If upgrading is not an option for you at this time, you can avoid the vulnerability by either disabling the Wasm reference types proposal or by disabling epoch interruption if you were previously enabling it.
GitHub Security Advisory: GHSA-gwc9-348x-qwv2
Package: wasmtime (RUST)
Severity: HIGH (CVSS 8.1)
CWE: CWE-416: Use After Free
Vulnerable versions: < 0.34.2
Patched in: 0.34.2

Summary: Use after free in Wasmtime

Details:
There is a use after free vulnerability in Wasmtime when both running Wasm that uses `externref`s and enabling [epoch interruption](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.epoch_interruption) in Wasmtime. If you are not explicitly enabling epoch interruption (it is disabled by default) then you are not affected. If you are explicitly disabling the Wasm reference types proposal (it is enabled by default) then you are also not affected.

The use after free is caused by Cranelift failing to emit stack maps when there are safepoints inside cold blocks. Cold blocks occur when epoch interruption is enabled. Cold blocks are emitted at the end of compiled functions, and change the order blocks are emitted versus defined. This reordering accidentally caused Cranelift to skip emitting some stack maps because it expected to emit the stack maps in block definition order, rather than block emission order. When Wasmtime would eventually collect garbage, it would fail to find live references on the stack because of the missing stack maps, think that they were unreferenced garbage, and therefore reclaim them. Then after the collection ended, the Wasm code could use the reclaimed-too-early references, which is a use after free.

This bug was discovered while extending our fuzz targets for `externref`s and GC in Wasmtime. The updated fuzz target thoroughly exercises these code paths and feature combinations now. We have also added a regression test for this bug. Released versions 0.34.2 and 0.35.2, which fix the vulnerability. We recommend all Wasmtime users upgrade to these patched versions. If upgrading is not an option for you at this time, you can avoid the vulnerability by either disabling the Wasm reference types proposal or by disabling epoch interruption if you were previously enabling it.
GitHub Security Advisory: GHSA-q2x5-6q7q-r872
Package: tremor-script (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-416: Use After Free
Vulnerable versions: >= 0.7.2, < 0.11.6
Patched in: 0.11.6

Summary: Use After Free in tremor-script

Details:
An issue was discovered in the tremor-script crate before 0.11.6 for Rust. A patch operation may result in a use-after-free.
GitHub Security Advisory: GHSA-mc36-5m36-hjh5
Package: slock (RUST)
Severity: HIGH (CVSS 8.1)
CWE: CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection'), CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Vulnerable versions: < 0.2.0
Patched in: 0.2.0

Summary: Data races in slock

Details:
An issue was discovered in the slock crate through 2020-11-17 for Rust. Slock<T> unconditionally implements Send and Sync.
GitHub Security Advisory: GHSA-8h4j-vm3r-vcq3
Package: rusqlite (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-416: Use After Free
Vulnerable versions: < 0.23.0
Patched in: 0.23.0

Summary: Use after free in rusqlite

Details:
An issue was discovered in the rusqlite crate before 0.23.0 for Rust. Memory safety can be violated via an Auxdata API use-after-free.
GitHub Security Advisory: GHSA-5r9g-j7jj-hw6c
Package: futures-util (RUST)
Severity: MODERATE (CVSS 5.5)
Vulnerable versions: >= 0.3.0, < 0.3.2
Patched in: 0.3.2

Summary: Improper `Sync` implementation on `FuturesUnordered` in futures-utils can cause data corruption

Details:
An issue was discovered in the futures-util crate before 0.3.2 for Rust. FuturesUnordered can lead to data corruption because Sync is mishandled.
GitHub Security Advisory: GHSA-xcf7-rvmh-g6q4
Package: openssl (RUST)
Severity: MODERATE (CVSS 4.5)
CWE: CWE-126: Buffer Over-read
Vulnerable versions: >= 0.10.0, < 0.10.55
Patched in: 0.10.55

Summary: `openssl` `X509VerifyParamRef::set_host` buffer over-read

Details:
When this function was passed an empty string, `openssl` would attempt to call `strlen` on it, reading arbitrary memory until it reached a NUL byte.
GitHub Security Advisory: GHSA-wfg4-322g-9vqv
Package: memoffset (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: < 0.6.2
Patched in: 0.6.2

Summary: memoffset allows reading uninitialized memory

Details:
memoffset allows attempt of reading data from address `0` with arbitrary type. This behavior is an undefined behavior because address `0` to `std::mem::size_of<T>` may not have valid bit-pattern with `T`. Old implementation dereferences uninitialized memory obtained from `std::mem::align_of`. Older implementation prior to it allows using uninitialized data obtained from `std::mem::uninitialized` with arbitrary type then compute offset by taking the address of field-projection. This may also result in an undefined behavior for "father" that includes (directly or transitively) type that [does not allow to be uninitialized](https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html).

This flaw was corrected by using `std::ptr::addr_of` in <https://github.com/Gilnaa/memoffset/pull/50>.
GitHub Security Advisory: GHSA-fqhp-rhm6-8rrj
Package: urlnorm (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: <= 0.1.4
Patched in: unpatched

Summary: Withdrawn Advisory: urlnorm vulnerable to Regular Expression Denial of Service

Details:
## Withdrawn Advisory
This advisory has been withdrawn because the security impact of the slow printing of URLs has been disputed. This link is maintained to preserve external references.

## Original Description
The urlnorm crate through 0.1.4 for Rust allows Regular Expression Denial of Service (ReDos) via a crafted URL to lib.rs.
GitHub Security Advisory: GHSA-wmff-grcw-jcfm
Package: tauri (RUST)
Severity: MODERATE (CVSS 4.8)
CWE: CWE-285: Improper Authorization
Vulnerable versions: = 1.4.0
Patched in: 1.4.1

Summary: Tauri vulnerable to Regression on Filesystem Scope Checks for Dotfiles

Details:
### Impact
The 1.4.0 release includes a regression on the filesystem scope check for dotfiles on Linux and macOS.

Previously dotfiles (eg. `$HOME/.ssh/`) were not implicitly allowed by the glob wildcard scopes (eg. `$HOME/*`), but a regression was introduced when a configuration option for this behavior was implemented and dotfiles were implicitly allowed.

Only Tauri applications using wildcard scopes in the `fs` endpoint are affected.
Only macOS and Linux systems are affected.

### Patches
The regression has been patched on `v1.4.1`.

### Workarounds
There are no known workarounds at this time, users should update to `v1.4.1` immediately.

### References
See the [original advisory](https://github.com/tauri-apps/tauri/security/advisories/GHSA-6mv3-wm7j-h4w5) for more information.

### For more Information
If you have any questions or comments about this advisory:

Open an issue in tauri
Email us at [security@tauri.app](mailto:security@tauri.app)