deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-xm67-587q-r2vw
Package: cranelift-codegen (RUST)
Severity: LOW (CVSS 3.1)
CWE: CWE-193: Off-by-one Error
Vulnerable versions: >= 0.88.0, < 0.91.1
Patched in: 0.91.1

Summary: wasmtime vulnerable to miscompilation of `i8x16.select` with the same inputs on x86_64

Details:
### Impact

Wasmtime's code generation backend, Cranelift, has a bug on x86_64 platforms for the WebAssembly `i8x16.select` instruction which will produce the wrong results when the same operand is provided to the instruction and some of the selected indices are greater than 16. There is an off-by-one error  in the calculation of the mask to the `pshufb` instruction which causes incorrect results to be returned if lanes are selected from the second vector.

The impact of this miscompilation is that the WebAssembly instruction can produce incorrect results for the `i8x16.select` instruction. This should have no effect on embedders and does not represent a sandbox escape, for example. Guest programs, however, may behave unexpectedly due to the incorrect result of this instruction. In extreme cases if a guest program is handling untrusted input then the guest program may deviate from its intended execution, for example calling an imported host function with different arguments than intended. This still does not impact embedders, however, because there is no form of privilege escalation with the guest.

At this time it's expected that this codegen pattern doesn't show up in the wild that often. LLVM-generated modules, for example, do not appear to conventionally or idiomatically generate code which would hit this bug. It is possible, however, to still write code which triggers this, so it's recommended for embedders to analyze existing modules to see if any are affected.

### Patches

This codegen bug has been fixed in Wasmtime 6.0.1, 5.0.1, and 4.0.1. Users are recommended to upgrade to these updated versions.

### Workarounds

If upgrading is not an option for you at this time, you can avoid this miscompilation by [disabling the Wasm simd proposal](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.wasm_simd)

```rust
config.wasm_simd(false);
```

Additionally the bug is only present on x86_64 hosts. Other platforms such as AArch64 and s390x are not affected.

### References

* [The WebAssembly simd proposal](https://github.com/webassembly/simd)
* [Mailing list announcement](https://groups.google.com/a/bytecodealliance.org/g/sec-announce/c/Mov-ItrNJsQ)
* [GitHub advisory](https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-xm67-587q-r2vw)
* [Commit to fix this issue on Wasmtime's `main` branch](https://github.com/bytecodealliance/wasmtime/commit/5dc2bbccbb363e474d2c9a1b8e38a89a43bbd5d1)

### For more information

If you have any questions or comments about this advisory:

* Reach out to us on [the Bytecode Alliance Zulip chat](https://bytecodealliance.zulipchat.com/#narrow/stream/217126-wasmtime)
* Open an issue in [the bytecodealliance/wasmtime repository](https://github.com/bytecodealliance/wasmtime/)
GitHub Security Advisory: GHSA-xm67-587q-r2vw
Package: wasmtime (RUST)
Severity: LOW (CVSS 3.1)
CWE: CWE-193: Off-by-one Error
Vulnerable versions: >= 6.0.0, < 6.0.1
Patched in: 6.0.1

Summary: wasmtime vulnerable to miscompilation of `i8x16.select` with the same inputs on x86_64

Details:
### Impact

Wasmtime's code generation backend, Cranelift, has a bug on x86_64 platforms for the WebAssembly `i8x16.select` instruction which will produce the wrong results when the same operand is provided to the instruction and some of the selected indices are greater than 16. There is an off-by-one error  in the calculation of the mask to the `pshufb` instruction which causes incorrect results to be returned if lanes are selected from the second vector.

The impact of this miscompilation is that the WebAssembly instruction can produce incorrect results for the `i8x16.select` instruction. This should have no effect on embedders and does not represent a sandbox escape, for example. Guest programs, however, may behave unexpectedly due to the incorrect result of this instruction. In extreme cases if a guest program is handling untrusted input then the guest program may deviate from its intended execution, for example calling an imported host function with different arguments than intended. This still does not impact embedders, however, because there is no form of privilege escalation with the guest.

At this time it's expected that this codegen pattern doesn't show up in the wild that often. LLVM-generated modules, for example, do not appear to conventionally or idiomatically generate code which would hit this bug. It is possible, however, to still write code which triggers this, so it's recommended for embedders to analyze existing modules to see if any are affected.

### Patches

This codegen bug has been fixed in Wasmtime 6.0.1, 5.0.1, and 4.0.1. Users are recommended to upgrade to these updated versions.

### Workarounds

If upgrading is not an option for you at this time, you can avoid this miscompilation by [disabling the Wasm simd proposal](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.wasm_simd)

```rust
config.wasm_simd(false);
```

Additionally the bug is only present on x86_64 hosts. Other platforms such as AArch64 and s390x are not affected.

### References

* [The WebAssembly simd proposal](https://github.com/webassembly/simd)
* [Mailing list announcement](https://groups.google.com/a/bytecodealliance.org/g/sec-announce/c/Mov-ItrNJsQ)
* [GitHub advisory](https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-xm67-587q-r2vw)
* [Commit to fix this issue on Wasmtime's `main` branch](https://github.com/bytecodealliance/wasmtime/commit/5dc2bbccbb363e474d2c9a1b8e38a89a43bbd5d1)

### For more information

If you have any questions or comments about this advisory:

* Reach out to us on [the Bytecode Alliance Zulip chat](https://bytecodealliance.zulipchat.com/#narrow/stream/217126-wasmtime)
* Open an issue in [the bytecodealliance/wasmtime repository](https://github.com/bytecodealliance/wasmtime/)
GitHub Security Advisory: GHSA-xm67-587q-r2vw
Package: wasmtime (RUST)
Severity: LOW (CVSS 3.1)
CWE: CWE-193: Off-by-one Error
Vulnerable versions: >= 5.0.0, < 5.0.1
Patched in: 5.0.1

Summary: wasmtime vulnerable to miscompilation of `i8x16.select` with the same inputs on x86_64

Details:
### Impact

Wasmtime's code generation backend, Cranelift, has a bug on x86_64 platforms for the WebAssembly `i8x16.select` instruction which will produce the wrong results when the same operand is provided to the instruction and some of the selected indices are greater than 16. There is an off-by-one error  in the calculation of the mask to the `pshufb` instruction which causes incorrect results to be returned if lanes are selected from the second vector.

The impact of this miscompilation is that the WebAssembly instruction can produce incorrect results for the `i8x16.select` instruction. This should have no effect on embedders and does not represent a sandbox escape, for example. Guest programs, however, may behave unexpectedly due to the incorrect result of this instruction. In extreme cases if a guest program is handling untrusted input then the guest program may deviate from its intended execution, for example calling an imported host function with different arguments than intended. This still does not impact embedders, however, because there is no form of privilege escalation with the guest.

At this time it's expected that this codegen pattern doesn't show up in the wild that often. LLVM-generated modules, for example, do not appear to conventionally or idiomatically generate code which would hit this bug. It is possible, however, to still write code which triggers this, so it's recommended for embedders to analyze existing modules to see if any are affected.

### Patches

This codegen bug has been fixed in Wasmtime 6.0.1, 5.0.1, and 4.0.1. Users are recommended to upgrade to these updated versions.

### Workarounds

If upgrading is not an option for you at this time, you can avoid this miscompilation by [disabling the Wasm simd proposal](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.wasm_simd)

```rust
config.wasm_simd(false);
```

Additionally the bug is only present on x86_64 hosts. Other platforms such as AArch64 and s390x are not affected.

### References

* [The WebAssembly simd proposal](https://github.com/webassembly/simd)
* [Mailing list announcement](https://groups.google.com/a/bytecodealliance.org/g/sec-announce/c/Mov-ItrNJsQ)
* [GitHub advisory](https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-xm67-587q-r2vw)
* [Commit to fix this issue on Wasmtime's `main` branch](https://github.com/bytecodealliance/wasmtime/commit/5dc2bbccbb363e474d2c9a1b8e38a89a43bbd5d1)

### For more information

If you have any questions or comments about this advisory:

* Reach out to us on [the Bytecode Alliance Zulip chat](https://bytecodealliance.zulipchat.com/#narrow/stream/217126-wasmtime)
* Open an issue in [the bytecodealliance/wasmtime repository](https://github.com/bytecodealliance/wasmtime/)
GitHub Security Advisory: GHSA-xm67-587q-r2vw
Package: wasmtime (RUST)
Severity: LOW (CVSS 3.1)
CWE: CWE-193: Off-by-one Error
Vulnerable versions: >= 1.0.0, < 4.0.1
Patched in: 4.0.1

Summary: wasmtime vulnerable to miscompilation of `i8x16.select` with the same inputs on x86_64

Details:
### Impact

Wasmtime's code generation backend, Cranelift, has a bug on x86_64 platforms for the WebAssembly `i8x16.select` instruction which will produce the wrong results when the same operand is provided to the instruction and some of the selected indices are greater than 16. There is an off-by-one error  in the calculation of the mask to the `pshufb` instruction which causes incorrect results to be returned if lanes are selected from the second vector.

The impact of this miscompilation is that the WebAssembly instruction can produce incorrect results for the `i8x16.select` instruction. This should have no effect on embedders and does not represent a sandbox escape, for example. Guest programs, however, may behave unexpectedly due to the incorrect result of this instruction. In extreme cases if a guest program is handling untrusted input then the guest program may deviate from its intended execution, for example calling an imported host function with different arguments than intended. This still does not impact embedders, however, because there is no form of privilege escalation with the guest.

At this time it's expected that this codegen pattern doesn't show up in the wild that often. LLVM-generated modules, for example, do not appear to conventionally or idiomatically generate code which would hit this bug. It is possible, however, to still write code which triggers this, so it's recommended for embedders to analyze existing modules to see if any are affected.

### Patches

This codegen bug has been fixed in Wasmtime 6.0.1, 5.0.1, and 4.0.1. Users are recommended to upgrade to these updated versions.

### Workarounds

If upgrading is not an option for you at this time, you can avoid this miscompilation by [disabling the Wasm simd proposal](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.wasm_simd)

```rust
config.wasm_simd(false);
```

Additionally the bug is only present on x86_64 hosts. Other platforms such as AArch64 and s390x are not affected.

### References

* [The WebAssembly simd proposal](https://github.com/webassembly/simd)
* [Mailing list announcement](https://groups.google.com/a/bytecodealliance.org/g/sec-announce/c/Mov-ItrNJsQ)
* [GitHub advisory](https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-xm67-587q-r2vw)
* [Commit to fix this issue on Wasmtime's `main` branch](https://github.com/bytecodealliance/wasmtime/commit/5dc2bbccbb363e474d2c9a1b8e38a89a43bbd5d1)

### For more information

If you have any questions or comments about this advisory:

* Reach out to us on [the Bytecode Alliance Zulip chat](https://bytecodealliance.zulipchat.com/#narrow/stream/217126-wasmtime)
* Open an issue in [the bytecodealliance/wasmtime repository](https://github.com/bytecodealliance/wasmtime/)
GitHub Security Advisory: GHSA-wm8x-php5-hvq6
Package: maligned (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: <= 0.2.1
Patched in: unpatched

Summary: Maligned causes incorrect deallocation

Details:
`maligned::align_first` manually allocates with an alignment larger than T, and then uses `Vec::from_raw_parts` on that allocation to get a `Vec<T>`.

[`GlobalAlloc::dealloc`](https://doc.rust-lang.org/std/alloc/trait.GlobalAlloc.html#tymethod.dealloc) requires that the `layout` argument must be the same layout that was used to allocate that block of memory.

When deallocating, `Box` and `Vec` may not respect the specified alignment and can cause undefined behavior.
GitHub Security Advisory: GHSA-5x36-7567-3cw6
Package: partial_sort (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-125: Out-of-bounds Read
Vulnerable versions: < 0.2.0
Patched in: 0.2.0

Summary: partial_sort contains Out-of-bounds Read in release mode

Details:
Affected versions of this crate were using a debug assertion to validate the `last` parameter of `partial_sort()`. This would allow invalid inputs to cause an out-of-bounds read instead of immediately panicking, when compiled without debug assertions.

All writes are bounds-checked, so the out-of-bounds memory access is read-only. This also means that the first attempted out-of-bounds write will panic, limiting the possible reads.

The accessible region is further limited by an initial bounds-checked read at `(last / 2) - 1`, i.e., it is proportional to the size of the vector.

This bug has been fixed in v0.2.0.
GitHub Security Advisory: GHSA-mrrw-grhq-86gf
Package: ascii (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 0.6.0, < 0.9.3
Patched in: 0.9.3

Summary: Ascii (crate) allows out-of-bounds array indexing in safe code

Details:
Affected version of this crate had implementation of `From<&mut AsciiStr>` for `&mut [u8]` and `&mut str`. This can result in out-of-bounds array indexing in safe code.

The flaw was corrected in commit [8a6c779](https://github.com/tomprogrammer/rust-ascii/pull/63/commits/8a6c7798c202766bd57d70fb8d12739dd68fb9dc) by removing those impls.
GitHub Security Advisory: GHSA-xr9w-x6gw-c9mj
Package: deno (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: < 1.31.0
Patched in: 1.31.0

Summary: Duplicate advisory: Deno vulnerable to Regular Expression Denial of Service

Details:
## Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of [GHSA-jc97-h3h9-7xh6](https://github.com/advisories/GHSA-jc97-h3h9-7xh6). This link is maintained to preserve external references.

## Original Description
Versions of the package deno before 1.31.0 are vulnerable to Regular Expression Denial of Service (ReDoS) due to the upgradeWebSocket function, which contains regexes in the form of /s*,s*/, used for splitting the Connection/Upgrade header. A specially crafted Connection/Upgrade header can be used to significantly slow down a web socket server. This issue has been patched in version 1.31.0.
GitHub Security Advisory: GHSA-mc8h-8q98-g5hr
Package: remove_dir_all (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-366: Race Condition within a Thread, CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition
Vulnerable versions: < 0.8.0
Patched in: 0.8.0

Summary: Race Condition Enabling Link Following and Time-of-check Time-of-use (TOCTOU) Race Condition in remove_dir_all

Details:
The `remove_dir_all` crate is a Rust library that offers additional features over the Rust standard library `fs::remove_dir_all` function. It suffers the same class of failure as the code it was layering over: TOCTOU race conditions, with the ability to cause arbitrary paths to be deleted by substituting a symlink for a path after the type of the path was checked.

Thanks to the Rust security team for identifying the problem and alerting us to it.
GitHub Security Advisory: GHSA-jw36-hf63-69r9
Package: libsqlite3-sys (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-129: Improper Validation of Array Index
Vulnerable versions: < 0.25.1
Patched in: 0.25.1

Summary: `libsqlite3-sys` via C SQLite improperly validates array index

Details:
SQLite 1.0.12 through 3.39.x before 3.39.2 sometimes allows an array-bounds overflow if billions of bytes are used in a string argument to a C API.
GitHub Security Advisory: GHSA-xw5j-gv2g-mjm2
Package: cortex-m-rt (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 0.7.0, < 0.7.3
Patched in: 0.7.3

Summary: Miscompilation in cortex-m-rt 0.7.1 and 0.7.2

Details:
Version 0.7.1 of the `cortex-m-rt` crate introduced a regression causing the stack to NOT be eight-byte aligned prior to calling `main` (or any other specified entrypoint), violating the [stack ABI of AAPCS32], the default ABI used by all Cortex-M targets. This regression is also present in version 0.7.2 of the `cortex-m-rt` crate.

This regression can cause certain compiler optimizations (which assume the eight-byte alignment) to produce incorrect behavior at runtime. This incorrect behavior has been [observed in real-world applications].

**It is advised that ALL users of `v0.7.1` and `v0.7.2` of the `cortex-m-rt` crate update to the latest version (`v0.7.3`), AS SOON AS POSSIBLE.** Users of `v0.7.0` and prior versions of `cortex-m-rt` are not affected by this regression.

It will be necessary to rebuild all affected firmware binaries, and flash or deploy the new firmware binaries to affected devices.

[stack ABI of AAPCS32]: https://github.com/ARM-software/abi-aa/blob/edd7460d87493fff124b8b5713acf71ffc06ee91/aapcs32/aapcs32.rst#6212stack-constraints-at-a-public-interface
[observed in real-world applications]: https://github.com/peter9477/test2
GitHub Security Advisory: GHSA-c8hq-x4mm-p6q6
Package: xcb (RUST)
Severity: MODERATE (CVSS 5.5)
CWE: CWE-415: Double Free, CWE-416: Use After Free
Vulnerable versions: < 1.0.0
Patched in: 1.0.0

Summary: Memory handling issues in xcb

Details:
An issue was discovered in the xcb crate through 2020-12-10 for Rust. base::Error does not have soundness. Because of the public ptr field, a use-after-free or double-free can occur.
GitHub Security Advisory: GHSA-cf4g-fcf8-3cr9
Package: pnet_packet (RUST)
Severity: MODERATE (CVSS 6.0)
Vulnerable versions: < 0.27.2
Patched in: 0.27.2

Summary: `pnet_packet` buffer overrun in `set_payload` setters

Details:
As indicated by this [issue](https://github.com/libpnet/libpnet/issues/449#issuecomment-663355987), a buffer overrun is possible in the `set_payload` setter of the various mutable "Packet" struct setters. The offending `set_payload` functions were defined within the struct `impl` blocks in earlier versions of the package, and later by the `packet` macro.

Fixed in the `packet` macro by [this](https://github.com/libpnet/libpnet/pull/455) PR.
GitHub Security Advisory: GHSA-w67w-mw4j-8qrv
Package: openssl-src (RUST)
Severity: CRITICAL (CVSS 9.1)
CWE: CWE-125: Out-of-bounds Read
Vulnerable versions: >= 300.0.0, < 300.0.12
Patched in: 300.0.12

Summary: openssl-src contains Read Buffer Overflow in X.509 Name Constraint

Details:
A read buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Note that this occurs
after certificate chain signature verification and requires either a CA to have signed the malicious certificate or for the application to
continue certificate verification despite failure to construct a path to a trusted issuer.

The read buffer overrun might result in a crash which could lead to a denial of service attack. In theory it could also result in the disclosure of private memory contents (such as private keys, or sensitive plaintext) although we are not aware of any working exploit leading to memory contents disclosure as of the time of release of this advisory.

In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects.
GitHub Security Advisory: GHSA-29xx-hcv2-c4cp
Package: openssl-src (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-476: NULL Pointer Dereference
Vulnerable versions: >= 300.0.0, < 300.0.12
Patched in: 300.0.12

Summary: openssl-src subject to Invalid pointer dereference in `d2i_PKCS7` functions

Details:
An invalid pointer dereference on read can be triggered when an application tries to load malformed PKCS7 data with the `d2i_PKCS7()`, `d2i_PKCS7_bio()` or `d2i_PKCS7_fp()` functions.

The result of the dereference is an application crash which could lead to a denial of service attack. The TLS implementation in OpenSSL does not call this function however third party applications might call these functions on untrusted data.
GitHub Security Advisory: GHSA-vxrh-cpg7-8vjr
Package: openssl-src (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-476: NULL Pointer Dereference
Vulnerable versions: >= 300.0.0, < 300.0.12
Patched in: 300.0.12

Summary: openssl-src subject to NULL dereference validating DSA public key

Details:
An invalid pointer dereference on read can be triggered when an application tries to check a malformed DSA public key by the `EVP_PKEY_public_check()` function. This will most likely lead to an application crash. This function can be called on public keys supplied from untrusted sources which could allow an attacker to cause a denial of service attack.

The TLS implementation in OpenSSL does not call this function but applications might call the function if there are additional security requirements imposed by standards such as FIPS 140-3.
GitHub Security Advisory: GHSA-vrh7-x64v-7vxq
Package: openssl-src (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-476: NULL Pointer Dereference
Vulnerable versions: >= 300.0.0, < 300.0.12
Patched in: 300.0.12

Summary: openssl-src contains `NULL` dereference during PKCS7 data verification

Details:
A `NULL` pointer can be dereferenced when signatures are being verified on PKCS7 `signed` or `signedAndEnveloped` data. In case the hash algorithm used for the signature is known to the OpenSSL library but the implementation of the hash algorithm is not available the digest initialization will fail. There is a missing check for the return value from the initialization function which later leads to invalid usage of the digest API most likely leading to a crash. The unavailability of an algorithm can be caused by using FIPS enabled configuration of providers or more commonly by not loading the legacy provider.

PKCS7 data is processed by the SMIME library calls and also by the time stamp (TS) library calls. The TLS implementation in OpenSSL does not call these functions however third party applications would be affected if they call these functions to verify signatures on untrusted data.
GitHub Security Advisory: GHSA-p2gm-ffr3-w2xw
Package: ckb (RUST)
Severity: LOW (CVSS 0.0)
Vulnerable versions: < 0.101.4
Patched in: 0.101.4

Summary: Nervos CKB vulnerable to low-resource flood DDoS attacks through network message

Details:
### Workarounds
* forbid request genesis through network request
* forbid requesting duplicate data  through network request
GitHub Security Advisory: GHSA-fjj4-2q73-jvgc
Package: ckb (RUST)
Severity: LOW (CVSS 0.0)
Vulnerable versions: >= 0.100.0
Patched in: unpatched

Summary: Nervos CKB calculation of program load cycles may be missed when executing in resume mode

Details:
### Impact
The calculation of program load cycles may be missed when executing in resume mode. Since the script execution order is now determined, this issue does not cause network splitting.