deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-w3vw-ccc5-qr8v
Package: tss-esapi (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: < 6.1.2
Patched in: 6.1.2

Summary: Use After Free in Context::start_auth_session

Details:
### Impact

**This issue only applies to applications starting authorization sessions using an explicit initial `nonce`.**

When [`Context::start_auth_session`](https://docs.rs/tss-esapi/7.0.1/tss_esapi/struct.Context.html#method.start_auth_session) was called with a `nonce` argument value of `Some(...)`, the nonce pointer passed down through FFI to `Esys_StartAuthSession` would be a dangling pointer, left over from a defunct instance of `TPM2B_NONCE`. This could lead to an incorrect value being used as a nonce, though whether that value is controllable is unclear (so should be assumed as possible). The error became apparent due to changes in v1.61.0 of the Rust compiler.

Logs indicating a failure due to this issue (with the 1.61.0 version of the Rust toolchain) look as follows:
```
2022-05-24T01:04:41.9131341Z WARNING:esys:src/tss2-esys/api/Esys_StartAuthSession.c:390:Esys_StartAuthSession_Finish() Received TPM Error 
2022-05-24T01:04:41.9132192Z ERROR:esys:src/tss2-esys/api/Esys_StartAuthSession.c:136:Esys_StartAuthSession() Esys Finish ErrorCode (0x000001d5) 
2022-05-24T01:04:41.9145124Z [2022-05-24T01:04:41Z ERROR tss_esapi::context::tpm_commands::session_commands] Error when creating a session: structure is the wrong size (associated with parameter number 1)
2022-05-24T01:04:41.9153816Z thread 'main' panicked at 'Call to start_auth_session failed: Tss2Error(FormatOne(FormatOneResponseCode { .0: 469, error_number: 21, parameter: true, format_selector: true, number: 1 }))', tss-esapi/tests/integration_tests/context_tests/tpm_commands/enhanced_authorization_ea_commands_tests.rs:870:14
```

### Patches
The issue has been patched in versions 6 and 7 of the `tss-esapi` crate. Please update to `7.1.0` or `6.1.2`.

### Workarounds
There is no workaround that achieves the same functionality.

### References
For more information on the cause of the issue and the fix, see [this](https://github.com/parallaxsecond/rust-tss-esapi/pull/344) PR.

For more details about the `TPM2_StartAuthSession` command see section 11.1 of [the TPM spec, part 3](https://trustedcomputinggroup.org/wp-content/uploads/TCG_TPM2_r1p59_Part3_Commands_pub.pdf), and section 19.6.3 of [part 1 of the same spec](https://trustedcomputinggroup.org/wp-content/uploads/TCG_TPM2_r1p59_Part1_Architecture_pub.pdf) for more information regarding session nonces.

### For more information
If you have any questions or comments about this advisory:
* Open an issue or discussion in [our repo](https://github.com/parallaxsecond/rust-tss-esapi)
* Get in touch on [our Slack channel](https://github.com/parallaxsecond/community#community-channel)
GitHub Security Advisory: GHSA-w3vw-ccc5-qr8v
Package: tss-esapi (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 7.0.0, < 7.1.0
Patched in: 7.1.0

Summary: Use After Free in Context::start_auth_session

Details:
### Impact

**This issue only applies to applications starting authorization sessions using an explicit initial `nonce`.**

When [`Context::start_auth_session`](https://docs.rs/tss-esapi/7.0.1/tss_esapi/struct.Context.html#method.start_auth_session) was called with a `nonce` argument value of `Some(...)`, the nonce pointer passed down through FFI to `Esys_StartAuthSession` would be a dangling pointer, left over from a defunct instance of `TPM2B_NONCE`. This could lead to an incorrect value being used as a nonce, though whether that value is controllable is unclear (so should be assumed as possible). The error became apparent due to changes in v1.61.0 of the Rust compiler.

Logs indicating a failure due to this issue (with the 1.61.0 version of the Rust toolchain) look as follows:
```
2022-05-24T01:04:41.9131341Z WARNING:esys:src/tss2-esys/api/Esys_StartAuthSession.c:390:Esys_StartAuthSession_Finish() Received TPM Error 
2022-05-24T01:04:41.9132192Z ERROR:esys:src/tss2-esys/api/Esys_StartAuthSession.c:136:Esys_StartAuthSession() Esys Finish ErrorCode (0x000001d5) 
2022-05-24T01:04:41.9145124Z [2022-05-24T01:04:41Z ERROR tss_esapi::context::tpm_commands::session_commands] Error when creating a session: structure is the wrong size (associated with parameter number 1)
2022-05-24T01:04:41.9153816Z thread 'main' panicked at 'Call to start_auth_session failed: Tss2Error(FormatOne(FormatOneResponseCode { .0: 469, error_number: 21, parameter: true, format_selector: true, number: 1 }))', tss-esapi/tests/integration_tests/context_tests/tpm_commands/enhanced_authorization_ea_commands_tests.rs:870:14
```

### Patches
The issue has been patched in versions 6 and 7 of the `tss-esapi` crate. Please update to `7.1.0` or `6.1.2`.

### Workarounds
There is no workaround that achieves the same functionality.

### References
For more information on the cause of the issue and the fix, see [this](https://github.com/parallaxsecond/rust-tss-esapi/pull/344) PR.

For more details about the `TPM2_StartAuthSession` command see section 11.1 of [the TPM spec, part 3](https://trustedcomputinggroup.org/wp-content/uploads/TCG_TPM2_r1p59_Part3_Commands_pub.pdf), and section 19.6.3 of [part 1 of the same spec](https://trustedcomputinggroup.org/wp-content/uploads/TCG_TPM2_r1p59_Part1_Architecture_pub.pdf) for more information regarding session nonces.

### For more information
If you have any questions or comments about this advisory:
* Open an issue or discussion in [our repo](https://github.com/parallaxsecond/rust-tss-esapi)
* Get in touch on [our Slack channel](https://github.com/parallaxsecond/community#community-channel)
GitHub Security Advisory: GHSA-75rw-34q6-72cr
Package: biscuit-auth (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: >= 1.0.0, < 2.0.0
Patched in: 2.0.0

Summary: Signature forgery in Biscuit

Details:
### Impact

The paper [Cryptanalysis of Aggregate Γ-Signature and Practical Countermeasures in Application to Bitcoin](https://eprint.iacr.org/2020/1484) defines a way to forge valid Γ-signatures, an algorithm that is used in the Biscuit specification version 1.
It would allow an attacker to create a token with any access level.

As Biscuit v1 was still an early version and not broadly deployed, we were able to contact all known users of Biscuit v1 and help them migrate to Biscuit v2.
We are not aware of any active exploitation of this vulnerability.

### Patches

The version 2 of the specification mandates a different algorithm than gamma signatures and as such is not affected by this vulnerability. The Biscuit implementations in Rust, Haskell, Go, Java and Javascript all have published versions following the v2 specification.

### Workarounds

There is no known workaround, any use of Biscuit v1 should be migrated to v2.

### References
[Cryptanalysis of Aggregate Γ-Signature and Practical Countermeasures in Application to Bitcoin](https://eprint.iacr.org/2020/1484)

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [biscuit-auth/biscuit](https://github.com/biscuit-auth/biscuit)
* Ask questions on [Matrix](https://matrix.to/#/#biscuit-auth:matrix.org)
GitHub Security Advisory: GHSA-r45x-ghr2-qjxc
Package: zeroize_derive (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-226: Sensitive Information in Resource Not Removed Before Reuse
Vulnerable versions: < 1.1.1
Patched in: 1.1.1

Summary: Duplicate Advisory: `#[zeroize(drop)]` doesn't implement `Drop` for `enum`s

Details:
## Duplicate Advisory
This advisory is a duplicate of [GHSA-c5hx-w945-j4pq](https://github.com/advisories/GHSA-c5hx-w945-j4pq). This link is preserved to maintain external references.

## Original Description
Affected versions of this crate did not implement `Drop` when `#[zeroize(drop)]` was used on an `enum`.

This can result in memory not being zeroed out after dropping it, which is exactly what is intended when adding this attribute.

The flaw was corrected in version 1.2 and `#[zeroize(drop)]` on `enum`s now properly implements `Drop`.
GitHub Security Advisory: GHSA-jmwx-r3gq-qq3p
Package: vec-const (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: < 2.0.0
Patched in: 2.0.0

Summary: vec-const attempts to construct a Vec from a pointer to a const slice

Details:
Affected versions of this crate claimed to construct a const `Vec` with nonzero length and capacity, but that cannot be done because such a `Vec` requires a pointer from an allocator.

The implementation was later changed to just construct a `std::borrow::Cow`.
GitHub Security Advisory: GHSA-9hpw-r23r-xgm5
Package: thread_local (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Vulnerable versions: < 1.1.4
Patched in: 1.1.4

Summary: Data race in `Iter` and `IterMut`

Details:
In the affected version of this crate, `{Iter, IterMut}::next` used a weaker memory ordering when loading values than what was required, exposing a potential data race
when iterating over a `ThreadLocal`'s values.

Crates using `Iter::next`, or `IterMut::next` are affected by this issue.
GitHub Security Advisory: GHSA-6692-8qqf-79jc
Package: tectonic_xdv (RUST)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: < 0.1.12
Patched in: 0.1.12

Summary: Duplicate Advisory: `Read` on uninitialized buffer may cause UB ('tectonic_xdv' crate)

Details:
## Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-qwvx-c8j7-5g75. This link is maintained to preserve external references.

## Original Description
Affected versions of this crate passes an uninitialized buffer to a user-provided `Read` implementation.

Arbitrary `Read` implementations can read from the uninitialized buffer (memory exposure) and also can return incorrect number of bytes written to the buffer. Reading from uninitialized memory produces undefined values that can quickly invoke undefined behavior.

The problem was fixed in commit `cdff034` by zero-initializing the buffer before passing it to a user-provided `Read` implementation.
GitHub Security Advisory: GHSA-xpww-g9jx-hp8r
Package: sha2 (RUST)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: = 0.9.7
Patched in: 0.9.8

Summary: Miscomputed sha2 results when using AVX2 backend

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

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

The crate has since been yanked, but any users who upgraded to v0.9.7 should
immediately upgrade to v0.9.8 and recompute any hashes which were previously
computed by v0.9.7.
GitHub Security Advisory: GHSA-978j-88f3-p5j3
Package: shamir (RUST)
Severity: LOW (CVSS 0.0)
Vulnerable versions: < 2.0.0
Patched in: 2.0.0

Summary: Threshold value is ignored (all shares are n=3)

Details:
Affected versions of this crate did not properly calculate secret shares requirements.

This reduces the security of the algorithm by restricting the crate to always
using a threshold value of three, rather than a configurable limit.

The flaw was corrected by correctly configuring the threshold.
GitHub Security Advisory: GHSA-2226-4v3c-cff8
Package: rustc-serialize (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: <= 0.3.24
Patched in: unpatched

Summary: Stack overflow in rustc_serialize when parsing deeply nested JSON

Details:
When parsing JSON using `json::Json::from_str`, there is no limit to the depth of the stack, therefore deeply nested objects can cause a stack overflow, which aborts the process.

Example code that triggers the vulnerability is

```rust
fn main() {
    let _ = rustc_serialize::json::Json::from_str(&"[0,[".repeat(10000));
}
```

[serde](https://crates.io/crates/serde) is recommended as a replacement to rustc_serialize.
GitHub Security Advisory: GHSA-cgw6-f3mj-h742
Package: rust-embed (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 6.3.0
Patched in: 6.3.0

Summary: RustEmbed generated `get` method allows for directory traversal when reading files from disk

Details:
When running in debug mode and the `debug-embed` (off by default) feature is
not enabled, the generated `get` method does not check that the input path is
a child of the folder given. 

This allows attackers to read arbitrary files in the file system if they have
control over the filename given. The following code will print the contents of
your `/etc/passwd` if adjusted with a correct number of `../`s depending on
where it is run from.

```rust
#[derive(rust_embed::RustEmbed)]
#[folder = "src/"]
pub struct Asset;

fn main() {
    let d = Asset::get("../../../etc/passwd").unwrap().data;
    println!("{}", String::from_utf8_lossy(&d));
}
```

The flaw was corrected by canonicalizing the input filename and ensuring that
it starts with the canonicalized folder path.
GitHub Security Advisory: GHSA-9c9f-7x9p-4wqp
Package: qcell (RUST)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: < 0.4.3
Patched in: 0.4.3

Summary: A malicious coder can get unsound access to TCell or TLCell memory

Details:
This is impossible to do by accident, but by carefully constructing
marker types to be covariant, a malicious coder can cheat the
singleton check in `TCellOwner` and `TLCellOwner`, giving unsound
access to cell memory.  This could take the form of getting two
mutable references to the same memory, or a mutable reference and an
immutable reference.

The fix is for the crate to internally force the marker type to be
invariant.  This blocks the conversion between covariant types which
Rust normally allows.
GitHub Security Advisory: GHSA-q579-9wp9-gfp2
Package: rdiff (RUST)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: <= 0.1.2
Patched in: unpatched

Summary: Window can read out of bounds if Read instance returns more bytes than buffer size

Details:
`rdiff` performs a diff of two provided strings or files. As part of its reading code it uses the return value of a `Read` instance to set the length of its internal character vector.

If the `Read` implementation claims that it has read more bytes than the length of the provided buffer, the length of the vector will be set to longer than its capacity. This causes `rdiff` APIs to return uninitialized memory in its API
methods.
GitHub Security Advisory: GHSA-3hxh-7jxm-59x4
Package: metrics-util (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: < 0.7.0
Patched in: 0.7.0

Summary: AtomicBucket<T> unconditionally implements Send/Sync

Details:
In the affected versions of the crate, `AtomicBucket<T>` unconditionally implements `Send`/`Sync` traits. Therefore, users can create a data race to the inner
`T: !Sync` by using the `AtomicBucket::data_with()` API.
Such data races can potentially cause memory corruption or other undefined behavior.

The flaw was fixed in commit 8e6daab by adding appropriate Send/Sync bounds to the Send/Sync impl of struct `Block<T>` (which is a data type contained inside `AtomicBucket<T>`).
GitHub Security Advisory: GHSA-8mv5-7x95-7wcf
Package: mopa (RUST)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: <= 0.2.2
Patched in: unpatched

Summary: `mopa` is technically unsound

Details:
The `mopa` crate redefines the deprecated `TraitObject` struct from `core::raw` like so:
```rust
#[repr(C)]
#[derive(Copy, Clone)]
#[doc(hidden)]
pub struct TraitObject {
    pub data: *mut (),
    pub vtable: *mut (),
}
```
This is done to then transmute a reference to a trait object (`&dyn Trait` for any trait `Trait`) into this struct and retrieve the `data` field for the purpose of downcasting. This is used to implement `downcast_ref_unchecked()`, in terms of which `downcast_ref()` is also implemented. Same goes for mutable reference downcasting and `Box` downcasting.

The Rust compiler explicitly reserves the right to change the memory layout of `&dyn Trait` for any trait `Trait`. The worst case scenario is that it swaps `data` and `vtable`, making an executable location breach and compromisation of ASLR possible, since reads from `data` would read `vtable` instead. Likewise, arbitrary code execution is also theoretically possible if reads of `vtable` generated by the compiler read `data` instead.

While, as of Rust 1.52, this unsound assumption still holds true, updating the compiler may silently create UB in a crate which previously compiled and run without issues, compromising the security of builds which are believed to be reproducible.

A potential strategy to resolve this has already been suggested in an issue on the GitHub repository of the crate.
GitHub Security Advisory: GHSA-m325-rxjv-pwph
Package: messagepack-rs (RUST)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: <= 0.8.1
Patched in: unpatched

Summary: Deserialization functions pass uninitialized memory to user-provided Read

Details:
Affected versions of this crate passed an uninitialized buffer to a
user-provided `Read` instance in:

* `deserialize_binary`
* `deserialize_string`
* `deserialize_extension_others`
* `deserialize_string_primitive`

This can result in safe `Read` implementations reading from the uninitialized
buffer leading to undefined behavior.
GitHub Security Advisory: GHSA-f67m-9j94-qv9j
Package: hyper (RUST)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: < 0.14.12
Patched in: 0.14.12

Summary: Parser creates invalid uninitialized value

Details:
Affected versions of this crate called `mem::uninitialized()` in the HTTP1 parser to create values of type `httparse::Header` (from the `httparse` crate).
This is unsound, since `Header` contains references and thus must be non-null.
 
The flaw was corrected by avoiding the use of `mem::uninitialized()`, using `MaybeUninit` instead.
GitHub Security Advisory: GHSA-28p5-7rg4-8v99
Package: gfx-auxil (RUST)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: <= 0.10.0
Patched in: unpatched

Summary: Reading on uninitialized buffer may cause UB ( `gfx_auxil::read_spirv()` )

Details:
Affected versions of this crate passes an uninitialized buffer to a user-provided `Read` implementation.
Arbitrary `Read` implementations can read from the uninitialized buffer (memory exposure) and also can return incorrect number of bytes written to the buffer.
Reading from uninitialized memory produces undefined values that can quickly invoke undefined behavior.
GitHub Security Advisory: GHSA-p56p-gq3f-whg8
Package: flumedb (RUST)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: < 0.1.6
Patched in: 0.1.6

Summary: `Read` on uninitialized buffer may cause UB ( `read_entry()` )

Details:
Affected versions of this crate passes an uninitialized buffer to a user-provided `Read` implementation.
There are two of such cases (`go_offset_log::read_entry()` & `offset_log::read_entry()`).

Arbitrary `Read` implementations can read from the uninitialized buffer (memory exposure) and also can return incorrect number of bytes written to the buffer.
Reading from uninitialized memory produces undefined values that can quickly invoke undefined behavior.
GitHub Security Advisory: GHSA-8gj8-hv75-gp94
Package: crossbeam (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: < 0.7.0
Patched in: 0.7.0

Summary: `SegQueue` creates zero value of any type

Details:
Affected versions of this crate called `mem::zeroed()` to create values of a user-supplied type `T`.
This is unsound e.g. if `T` is a reference type (which must be non-null).
 
The flaw was corrected by avoiding the use of `mem::zeroed()`, using `MaybeUninit` instead.
GitHub Security Advisory: GHSA-j8q9-5rp9-4mv9
Package: diesel (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-416: Use After Free
Vulnerable versions: < 1.4.6
Patched in: 1.4.6

Summary: Fix a use-after-free bug in diesels Sqlite backend

Details:
An issue was discovered in the diesel crate before 1.4.6 for Rust. There is a use-after-free in the SQLite backend because the semantics of sqlite3_column_name are not followed.
GitHub Security Advisory: GHSA-6888-wf7j-34jq
Package: crossbeam-queue (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: < 0.2.3
Patched in: 0.2.3

Summary: `SegQueue` creates zero value of any type

Details:
Affected versions of this crate called `mem::zeroed()` to create values of a user-supplied type `T`.
This is unsound e.g. if `T` is a reference type (which must be non-null).
 
The flaw was corrected by avoiding the use of `mem::zeroed()`, using `MaybeUninit` instead.
GitHub Security Advisory: GHSA-9g55-pg62-m8hh
Package: crossbeam-channel (RUST)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: < 0.4.3
Patched in: 0.4.3

Summary: Channel creates zero value of any type

Details:
Affected versions of this crate called `mem::zeroed()` to create values of a user-supplied type `T`.
This is unsound e.g. if `T` is a reference type (which must be non-null).
 
The flaw was corrected by avoiding the use of `mem::zeroed()`, using `MaybeUninit` instead.
GitHub Security Advisory: GHSA-cxcc-q839-2cw9
Package: columnar (RUST)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: <= 0.0.19
Patched in: unpatched

Summary: columnar: `Read` on uninitialized buffer may cause UB (ColumnarReadExt::read_typed_vec())

Details:
Affected versions of this crate passes an uninitialized buffer to a user-provided `Read` implementation (`ColumnarReadExt::read_typed_vec()`).
Arbitrary `Read` implementations can read from the uninitialized buffer (memory exposure) and also can return incorrect number of bytes written to the buffer.
Reading from uninitialized memory produces undefined values that can quickly invoke undefined behavior.
GitHub Security Advisory: GHSA-hmx9-jm3v-33hv
Package: buffoon (RUST)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: <= 0.5.0
Patched in: unpatched

Summary: InputStream::read_exact : `Read` on uninitialized buffer causes UB

Details:
Affected versions of this crate passes an uninitialized buffer to a user-provided `Read` implementation.
Arbitrary `Read` implementations can read from the uninitialized buffer (memory exposure) and also can return incorrect number of bytes written to the buffer.
Reading from uninitialized memory produces undefined values that can quickly invoke undefined behavior.
GitHub Security Advisory: GHSA-5phc-849h-vcxg
Package: bronzedb-protocol (RUST)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: <= 0.1.0
Patched in: unpatched

Summary: `Read` on uninitialized buffer can cause UB (impl of `ReadKVExt`)

Details:
Affected versions of this crate passes an uninitialized buffer to a user-provided `Read` implementation.
Arbitrary `Read` implementations can read from the uninitialized buffer (memory exposure) and also can return incorrect number of bytes written to the buffer.
Reading from uninitialized memory produces undefined values that can quickly invoke undefined behavior.
GitHub Security Advisory: GHSA-c8rq-crxj-mj9m
Package: async-h1 (RUST)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 2.3.0
Patched in: 2.3.0

Summary: Async-h1 request smuggling possible with long unread bodies

Details:
An issue was discovered in the async-h1 crate before 2.3.0 for Rust. Request smuggling can occur when used behind a reverse proxy.
GitHub Security Advisory: GHSA-72r2-rg28-47v9
Package: bite (RUST)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: <= 0.0.5
Patched in: unpatched

Summary: `read` on uninitialized buffer may cause UB (bite::read::BiteReadExpandedExt::read_framed_max)

Details:
Affected versions of this crate calls a user provided `Read` implementation on an uninitialized buffer. `Read` on uninitialized buffer is defined as undefined behavior in Rust.