deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-jq65-29v4-4x35
Package: openssl-src (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-476: NULL Pointer Dereference
Vulnerable versions: >= 111.6.0, < 111.9.0
Patched in: 111.9.0

Summary: Null pointer deference in openssl-src 

Details:
Server or client applications that call the SSL_check_chain() function during or after a TLS 1.3 handshake may crash due to a NULL pointer dereference as a result of incorrect handling of the "signature_algorithms_cert" TLS extension. The crash occurs if an invalid or unrecognised signature algorithm is received from the peer. This could be exploited by a malicious peer in a Denial of Service attack. OpenSSL version 1.1.1d, 1.1.1e, and 1.1.1f are affected by this issue. This issue did not affect OpenSSL versions prior to 1.1.1d. Fixed in OpenSSL 1.1.1g (Affected 1.1.1d-1.1.1f).
GitHub Security Advisory: GHSA-87mf-9wg6-ppf8
Package: ouroboros (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: < 0.16.0
Patched in: 0.16.0

Summary: Ouroboros is Unsound

Details:
In 0.15.0 and prior, Ouroboros works internally by creating a struct where all uses of 'this are replaced by 'static. However, a recent addition to Miri checks that references passed to functions are valid during the entire execution of the function, even when those references are passed inside a struct. This poses an issue for dropping self-referencing values, as the reference becomes invalid during the dropping process. Effectively, since self-referencing structs are not allowed in vanilla Rust, there is no allowance for dropping data during a function that has also been given a reference to that data. There's usually no way to pass a and &a to the same function.

A fix was attempted, where the struct would be turned in to a raw byte array and only transformed back into the underlying data type inside each function. This is allowable as a reference can be created and die over the body of a function, as long as the reference was created inside the function. However, this is also not sound if the original struct contains padding. There is no way to initialize padding bytes to a known value that Miri will accept, so when it is cast to an array some of the bytes contain uninitialized values. This is not acceptable (despite the fact that these bytes are never read) due to the potential for optimizations that may read from the uninitialized bytes. Besides which, this fix does not allow for template or constant parameters as there is no way to check the size of a templated type without giving specific, concrete values for the template parameters.

The final solution was to use this fix while wrapping the raw byte array in MaybeUninit<>.
GitHub Security Advisory: GHSA-853p-5678-hv8f
Package: ink_env (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-253: Incorrect Check of Function Return Value, CWE-754: Improper Check for Unusual or Exceptional Conditions
Vulnerable versions: >= 4.0.0, < 4.2.1
Patched in: 4.2.1

Summary: ink! vulnerable to incorrect decoding of storage value when using `DelegateCall`

Details:
### Summary
The return value when using delegate call mechanics, either through [`CallBuilder::delegate`](https://docs.rs/ink_env/4.2.0/ink_env/call/struct.CallBuilder.html#method.delegate) or [`ink_env::invoke_contract_delegate`](https://docs.rs/ink_env/4.2.0/ink_env/fn.invoke_contract_delegate.html), is being decoded incorrectly.

### Description
Consider this minimal example:

```rust
// First contract, this will be performing a delegate call to the `Callee`.
#[ink(storage)]
pub struct Caller {
    value: u128,
}

#[ink(message)]
pub fn get_value(&self, callee_code_hash: Hash) -> u128 {
    let result = build_call::<DefaultEnvironment>()
        .delegate(callee_code_hash)
        .exec_input(ExecutionInput::new(Selector::new(ink::selector_bytes!(
            "get_value"
        ))))
        .returns::<u128>()
        .invoke();

    result
}

// Different contract, using this code hash for the delegate call.
#[ink(storage)]
pub struct Callee {
    value: u128,
}

#[ink(message)]
pub fn get_value(&self) -> u128 {
    self.value
}
```

In this example we are executing the `Callee` code in the context of the `Caller` contract. This means we'll be using the storage values of the `Caller` contract.

Running this code we expect the delegate call to return `value` as it was stored in the `Caller` contract. However, due to the reported bug a different value is returned (for the case of `uint`s it is `256` times the expected value).

### Impact
After conducting an analysis of the on-chain deployments of ink! contracts on Astar, Shiden, Aleph Zero, Amplitude and Pendulum, we have found that no contracts on those chains have been affected by the issue.

This bug was related to the mechanics around decoding a call's return buffer, which was changed as part of https://github.com/paritytech/ink/pull/1450. Since this feature was only released in ink! 4.0.0 no previous versions are affected.

### Mitigations
If you have an ink! 4.x series contract, please update it to the [4.2.1](https://github.com/paritytech/ink/releases/tag/v4.2.1) patch release that we just published. 

### Credits
Thank you Facundo Lerena from [CoinFabrik](https://www.coinfabrik.com) for reporting this problem in a well-structured and responsible way.
GitHub Security Advisory: GHSA-853p-5678-hv8f
Package: ink (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-253: Incorrect Check of Function Return Value, CWE-754: Improper Check for Unusual or Exceptional Conditions
Vulnerable versions: >= 4.0.0, < 4.2.1
Patched in: 4.2.1

Summary: ink! vulnerable to incorrect decoding of storage value when using `DelegateCall`

Details:
### Summary
The return value when using delegate call mechanics, either through [`CallBuilder::delegate`](https://docs.rs/ink_env/4.2.0/ink_env/call/struct.CallBuilder.html#method.delegate) or [`ink_env::invoke_contract_delegate`](https://docs.rs/ink_env/4.2.0/ink_env/fn.invoke_contract_delegate.html), is being decoded incorrectly.

### Description
Consider this minimal example:

```rust
// First contract, this will be performing a delegate call to the `Callee`.
#[ink(storage)]
pub struct Caller {
    value: u128,
}

#[ink(message)]
pub fn get_value(&self, callee_code_hash: Hash) -> u128 {
    let result = build_call::<DefaultEnvironment>()
        .delegate(callee_code_hash)
        .exec_input(ExecutionInput::new(Selector::new(ink::selector_bytes!(
            "get_value"
        ))))
        .returns::<u128>()
        .invoke();

    result
}

// Different contract, using this code hash for the delegate call.
#[ink(storage)]
pub struct Callee {
    value: u128,
}

#[ink(message)]
pub fn get_value(&self) -> u128 {
    self.value
}
```

In this example we are executing the `Callee` code in the context of the `Caller` contract. This means we'll be using the storage values of the `Caller` contract.

Running this code we expect the delegate call to return `value` as it was stored in the `Caller` contract. However, due to the reported bug a different value is returned (for the case of `uint`s it is `256` times the expected value).

### Impact
After conducting an analysis of the on-chain deployments of ink! contracts on Astar, Shiden, Aleph Zero, Amplitude and Pendulum, we have found that no contracts on those chains have been affected by the issue.

This bug was related to the mechanics around decoding a call's return buffer, which was changed as part of https://github.com/paritytech/ink/pull/1450. Since this feature was only released in ink! 4.0.0 no previous versions are affected.

### Mitigations
If you have an ink! 4.x series contract, please update it to the [4.2.1](https://github.com/paritytech/ink/releases/tag/v4.2.1) patch release that we just published. 

### Credits
Thank you Facundo Lerena from [CoinFabrik](https://www.coinfabrik.com) for reporting this problem in a well-structured and responsible way.
GitHub Security Advisory: GHSA-c79c-gwph-gqfm
Package: net2 (RUST)
Severity: MODERATE (CVSS 5.5)
Vulnerable versions: < 0.2.36
Patched in: 0.2.36

Summary: `net2` invalidly assumes the memory layout of std::net::SocketAddr

Details:
The net2 crate has assumed std::net::SocketAddrV4 and std::net::SocketAddrV6 have the same memory layout as the system C representation sockaddr. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the memory layout, and this will cause invalid memory access if the standard library changes the implementation. No warnings or errors will be emitted once the change happens.
GitHub Security Advisory: GHSA-7gf7-jv65-wjmh
Package: xml-rs (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-611: Improper Restriction of XML External Entity Reference, CWE-617: Reachable Assertion
Vulnerable versions: >= 0.8.9, < 0.8.14
Patched in: 0.8.14

Summary: xml-rs vulnerable to denial of service via invalid token in XML document

Details:
The xml-rs crate >= 0.8.9 and < 0.8.14 for Rust and Crab allows a denial of service (panic) via an invalid <! token (such as <!DOCTYPEs/%<!A nesting) in an XML document.
GitHub Security Advisory: GHSA-xm9m-2vj8-fmfr
Package: toodee (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-908: Use of Uninitialized Resource
Vulnerable versions: < 0.3.0
Patched in: 0.3.0

Summary: Uninitialized memory access in toodee

Details:
An issue was discovered in the toodee crate before 0.3.0 for Rust. The row-insertion feature allows attackers to read the contents of uninitialized memory locations.
GitHub Security Advisory: GHSA-3cj3-jrrp-9rxf
Package: xcb (RUST)
Severity: HIGH (CVSS 8.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 transmutation to the wrong type can happen after xcb::base::cast_event uses std::mem::transmute to return a reference to an arbitrary type.
GitHub Security Advisory: GHSA-mp6r-fgw2-rxfx
Package: xcb (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-657: Violation of Secure Design Principles
Vulnerable versions: < 1.0.0
Patched in: 1.0.0

Summary: Arbitrary return types in xcb

Details:
The function xcb::xproto::GetPropertyReply::value() returns a slice of type T where T is an unconstrained type parameter. The raw bytes received from the X11 server are interpreted as the requested type. The users of the xcb crate are advised to only call this function with the intended types. These are u8, u16, and u32.

This issue is tracked here: https://github.com/rust-x-bindings/rust-xcb/issues/95
GitHub Security Advisory: GHSA-2xpg-3hx4-fm9r
Package: xcb (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-125: Out-of-bounds Read
Vulnerable versions: < 1.0.0
Patched in: 1.0.0

Summary: Out of bounds read in xcb

Details:
An issue was discovered in the xcb crate through 2021-02-04 for Rust. It has a soundness violation because there is an out-of-bounds read in xcb::xproto::change_property(), as demonstrated by a format=32 T=u8 situation where out-of-bounds bytes are sent to an X server.
GitHub Security Advisory: GHSA-qrqq-9c63-xfrg
Package: tower-http (RUST)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: < 0.1.3
Patched in: 0.1.3

Summary: tower-http's improper validation of Windows paths could lead to directory traversal attack

Details:
`tower_http::services::fs::ServeDir` 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.

See [tower-http#204] for more details.

[tower-http#204]: https://github.com/tower-rs/tower-http/pull/204
GitHub Security Advisory: GHSA-qrqq-9c63-xfrg
Package: tower-http (RUST)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: = 0.2.0
Patched in: 0.2.1

Summary: tower-http's improper validation of Windows paths could lead to directory traversal attack

Details:
`tower_http::services::fs::ServeDir` 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.

See [tower-http#204] for more details.

[tower-http#204]: https://github.com/tower-rs/tower-http/pull/204
GitHub Security Advisory: GHSA-wwh2-r387-g5rm
Package: tower-http (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 0.1.3
Patched in: 0.1.3

Summary: tower-http's improper validation of Windows paths could lead to directory traversal attack

Details:
`tower_http::services::fs::ServeDir` 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-wwh2-r387-g5rm
Package: tower-http (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: >= 0.2.0, < 0.2.1
Patched in: 0.2.1

Summary: tower-http's improper validation of Windows paths could lead to directory traversal attack

Details:
`tower_http::services::fs::ServeDir` 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-2f5j-3mhq-xv58
Package: sys-info (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-415: Double Free
Vulnerable versions: < 0.8.0
Patched in: 0.8.0

Summary: Double free in sys-info 

Details:
Affected versions of sys-info use a static, global, list to store temporary disk information while running. The function that cleans up this list, DFCleanup, assumes a single threaded environment and will try to free the same memory twice in a multithreaded environment. This results in consistent double-frees and segfaults when calling sys_info::disk_info from multiple threads at once. The issue was fixed by moving the global variable into a local scope.
GitHub Security Advisory: GHSA-fg7r-2g4j-5cgr
Package: tokio (RUST)
Severity: HIGH (CVSS 8.1)
CWE: CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Vulnerable versions: >= 0.1.14, < 1.8.4
Patched in: 1.8.4

Summary: Race Condition in tokio

Details:
If a tokio::sync::oneshot channel is closed (via the oneshot::Receiver::close method), a data race may occur if the oneshot::Sender::send method is called while the corresponding oneshot::Receiver is awaited or calling try_recv.

When these methods are called concurrently on a closed channel, the two halves of the channel can concurrently access a shared memory location, resulting in a data race. This has been observed to cause memory corruption.

Note that the race only occurs when both halves of the channel are used after the Receiver half has called close. Code where close is not used, or where the Receiver is not awaited and try_recv is not called after calling close, is not affected.
GitHub Security Advisory: GHSA-fg7r-2g4j-5cgr
Package: tokio (RUST)
Severity: HIGH (CVSS 8.1)
CWE: CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Vulnerable versions: >= 1.9.0, < 1.13.1
Patched in: 1.13.1

Summary: Race Condition in tokio

Details:
If a tokio::sync::oneshot channel is closed (via the oneshot::Receiver::close method), a data race may occur if the oneshot::Sender::send method is called while the corresponding oneshot::Receiver is awaited or calling try_recv.

When these methods are called concurrently on a closed channel, the two halves of the channel can concurrently access a shared memory location, resulting in a data race. This has been observed to cause memory corruption.

Note that the race only occurs when both halves of the channel are used after the Receiver half has called close. Code where close is not used, or where the Receiver is not awaited and try_recv is not called after calling close, is not affected.
GitHub Security Advisory: GHSA-wcvp-r8j8-47pc
Package: toodee (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-415: Double Free
Vulnerable versions: < 0.3.0
Patched in: 0.3.0

Summary: Double free in toodee

Details:
When inserting rows from an iterator at a particular index, toodee would shift items over, duplicating their ownership. The space reserved for the new elements was based on the len() returned by the ExactSizeIterator.

This could result in elements in the array being freed twice if the iterator panics. Uninitialized or previously freed elements could also be exposed if the len() didn't match the number of elements.

These issues were fixed in commit `ced70c17` by temporarily setting the length of the array smaller while processing it and adding assertions on the number of elements returned by the iterator.
GitHub Security Advisory: GHSA-8vxv-2g8p-2249
Package: totp-rs (RUST)
Severity: MODERATE (CVSS 4.2)
CWE: CWE-203: Observable Discrepancy, CWE-208: Observable Timing Discrepancy
Vulnerable versions: < 1.1.0
Patched in: 1.1.0

Summary: Observable Timing Discrepancy in totp-rs

Details:
### Impact
Token comparison was not constant time, and could theorically be used to guess value of an TOTP token, and thus reuse it in the same time window. The attacker would have to know the password beforehand nonetheless.

### Patches
Library now used constant-time comparison.

### Workarounds
No.

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [totp-rs](https://github.com/constantoine/totp-rs)
* Email us at [cleo.rebert@gmail.com](mailto:cleo.rebert@gmail.com)
GitHub Security Advisory: GHSA-49fq-pw77-6qxj
Package: string-interner (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-416: Use After Free
Vulnerable versions: < 0.6.4
Patched in: 0.6.4

Summary: Use after free in string-interner

Details:
Affected versions of this crate did not clone contained strings when an interner is cloned. Interners have raw pointers to the contained strings, and they keep pointing the strings which the old interner owns, after the interner is cloned. If a new cloned interner is alive and the old original interner is dead, the new interner has dangling pointers to the old interner's storage, which is already dropped.

This allows an attacker to read the already freed memory. The dangling pointers are used by the interners to check a string is already interned. An attacker can do brute force attack to get the data pointed by the dangling pointer.
GitHub Security Advisory: GHSA-49fq-pw77-6qxj
Package: string-interner (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-416: Use After Free
Vulnerable versions: >= 0.7.0, < 0.7.1
Patched in: 0.7.1

Summary: Use after free in string-interner

Details:
Affected versions of this crate did not clone contained strings when an interner is cloned. Interners have raw pointers to the contained strings, and they keep pointing the strings which the old interner owns, after the interner is cloned. If a new cloned interner is alive and the old original interner is dead, the new interner has dangling pointers to the old interner's storage, which is already dropped.

This allows an attacker to read the already freed memory. The dangling pointers are used by the interners to check a string is already interned. An attacker can do brute force attack to get the data pointed by the dangling pointer.
GitHub Security Advisory: GHSA-3pp4-64mp-9cg9
Package: tremor-script (RUST)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: >= 0.7.2, < 0.11.6
Patched in: 0.11.6

Summary: Memory Safety Issue when using `patch` or `merge` on `state` and assign the result back to `state`

Details:
Affected versions of this crate maintains references to memory that might have been freed already.
If affects the following two `tremor-script` language constructs:

* A [Merge](https://www.tremor.rs/docs/tremor-script/index#merge) where we assign the result back to the target expression
  and the expression to be merged needs to reference the `event`:

```
let state = merge state of event end;
```

* A [Patch](https://www.tremor.rs/docs/tremor-script/index#patch) where we assign the result back to the target expression
  and the patch operations used need to reference the `event`:

```
let state = patch state of insert event.key => event.value end;
```

For constructs like this (it doesnt matter what is references in the expression to be merged or the patch operations) an optimization
was applied to manipulate the target value in-place, instead of cloning it.

Our `Value` struct which underpins all event data in `tremor-script`, is representing as borrowed strings `beef::Cow<'lifetime, str>` 
that reference the actual `Vec<u8>` the event is based upon. We keep the raw byte-array next to the event structure inside our `Event` struct as a self-referential struct,
so we make sure that the structured `Value` and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patche `event` data or static data.
When `state` was introduced to `tremor-script` a new possibility existed, to keep `Value` data around for longer than the lifetime of an event.
If `event` data is merged or patched into `state` without cloning `state` first, it can still reference keys or values from
the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.


## Workaround

If an upgrade is not possible, a possible workaround is to avoid the optimization
by introducing a temporary variable and not immediately reassigning to `state`:

```
let tmp = merge state of event end;
let state = tmp
```

## Fix

The flaw was corrected in `tremor-script` version 0.11.6 via commit [1a2efcd](https://github.com/tremor-rs/tremor-runtime/commit/1a2efcdbe68e5e7fd0a05836ac32d2cde78a0b2e) by removing the optimization
and always clone the target expression of a [Merge](https://www.tremor.rs/docs/tremor-script/index#merge) or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.
GitHub Security Advisory: GHSA-9qvw-46gf-4fv8
Package: tremor-script (RUST)
Severity: HIGH (CVSS 7.5)
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 merge operation may result in a use-after-free.
GitHub Security Advisory: GHSA-69gw-hgj3-45m7
Package: smallvec (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-787: Out-of-bounds Write
Vulnerable versions: >= 0.6.3, < 0.6.10
Patched in: 0.6.10

Summary: Memory corruption in smallvec

Details:
Attempting to call grow on a spilled SmallVec with a value less than the current capacity causes corruption of memory allocator data structures. An attacker that controls the value passed to grow may exploit this flaw to obtain memory contents or gain remote code execution.
GitHub Security Advisory: GHSA-2v78-j59h-fmpf
Package: safe-transmute (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer
Vulnerable versions: >= 0.4.0, < 0.10.1
Patched in: 0.10.1

Summary: Heap overflow or corruption in safe-transmute

Details:
Affected versions of this crate switched the length and capacity arguments in the Vec::from_raw_parts() constructor, which could lead to memory corruption or data leakage.