deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-7f6x-jwh5-m9r4
Package: cranelift-codegen (RUST)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-682: Incorrect Calculation
Vulnerable versions: < 0.85.2
Patched in: 0.85.2

Summary: Cranelift vulnerable to miscompilation of constant values in division on AArch64

Details:
### Impact

There was a bug in Wasmtime's code generator, Cranelift, for AArch64 targets where constant divisors could result in incorrect division results at runtime. The translation rules for constants did not take into account whether sign- or zero-extension should happen, which resulted in an incorrect value being placed into a register when a division was encountered. For example, a constant 32-bit unsigned divisor of `0xfffffffe` would be incorrectly sign-extended to 64-bits to `0xfffffffffffffffe`. Any kind of division of operands smaller than 64 bits is implemented with a 64-bit division instruction which would then result in an incorrect result because the divisor was larger than expected.

The impact of this bug is that programs executing within the WebAssembly sandbox would not behave according to the WebAssembly specification. This means that it is hypothetically possible for execution within the sandbox to go awry and WebAssembly programs could produce unexpected results. This should not impact hosts executing WebAssembly, but does affect the correctness of guest programs.

This bug was found with differential fuzzing of Wasmtime against other engines on the AArch64 platform. Fuzzing on AArch64 is not regularly performed at this time and the Wasmtime team is investigating how best to continuously fuzz AArch64 in the same manner as x86_64.

### Patches

This bug has been patched and users should upgrade to Wasmtime version 0.38.2.

### Workarounds

If upgrading is not an option at this time, direct users of Cranelift that control the exact Cranelift instructions being compiled can avoid the vulnerability by explicitly extending constant divisors to 64 bits using either the `sextend.i64` or the `uextend.i64` operation.

Note, though, that this issue only affects the AArch64 targets. Other platforms are not affected.

### 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-7f6x-jwh5-m9r4
Package: wasmtime (RUST)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-682: Incorrect Calculation
Vulnerable versions: < 0.38.2
Patched in: 0.38.2

Summary: Cranelift vulnerable to miscompilation of constant values in division on AArch64

Details:
### Impact

There was a bug in Wasmtime's code generator, Cranelift, for AArch64 targets where constant divisors could result in incorrect division results at runtime. The translation rules for constants did not take into account whether sign- or zero-extension should happen, which resulted in an incorrect value being placed into a register when a division was encountered. For example, a constant 32-bit unsigned divisor of `0xfffffffe` would be incorrectly sign-extended to 64-bits to `0xfffffffffffffffe`. Any kind of division of operands smaller than 64 bits is implemented with a 64-bit division instruction which would then result in an incorrect result because the divisor was larger than expected.

The impact of this bug is that programs executing within the WebAssembly sandbox would not behave according to the WebAssembly specification. This means that it is hypothetically possible for execution within the sandbox to go awry and WebAssembly programs could produce unexpected results. This should not impact hosts executing WebAssembly, but does affect the correctness of guest programs.

This bug was found with differential fuzzing of Wasmtime against other engines on the AArch64 platform. Fuzzing on AArch64 is not regularly performed at this time and the Wasmtime team is investigating how best to continuously fuzz AArch64 in the same manner as x86_64.

### Patches

This bug has been patched and users should upgrade to Wasmtime version 0.38.2.

### Workarounds

If upgrading is not an option at this time, direct users of Cranelift that control the exact Cranelift instructions being compiled can avoid the vulnerability by explicitly extending constant divisors to 64 bits using either the `sextend.i64` or the `uextend.i64` operation.

Note, though, that this issue only affects the AArch64 targets. Other platforms are not affected.

### 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-5fhj-g3p3-pq9g
Package: cranelift-codegen (RUST)
Severity: MODERATE (CVSS 6.4)
CWE: CWE-416: Use After Free
Vulnerable versions: >= 0.84.0, < 0.85.2
Patched in: 0.85.2

Summary: Wasmtime vulnerable to Use After Free with `externref`s

Details:
There is a bug in Wasmtime's code generator, Cranelift, where functions using reference types may be incorrectly missing metadata required for runtime garbage collection (GC). This means that if a GC happens at runtime then the collector will mistakenly think some Wasm stack frames do not have live references to garbage collected values and therefore reclaim and deallocate them. The function can then subsequently continue to use the values, leading later to use-after-free bugs. This bug was introduced in Cranelift's migration to the `regalloc2` register allocator in the Wasmtime 0.37.0 release on 2022-05-20. This bug has been patched and users should upgrade to Wasmtime version 0.38.2.

Mitigations for this issue can be achieved by doing one of:

* Disabling the reference types proposal by passing `false` to [`wasmtime::Config::wasm_reference_types`](https://docs.rs/wasmtime/0.38.0/wasmtime/struct.Config.html#method.wasm_reference_types).
* Downgrading to Wasmtime 0.36.0 or prior.
GitHub Security Advisory: GHSA-5fhj-g3p3-pq9g
Package: wasmtime (RUST)
Severity: MODERATE (CVSS 6.4)
CWE: CWE-416: Use After Free
Vulnerable versions: >= 0.37.0, < 0.38.2
Patched in: 0.38.2

Summary: Wasmtime vulnerable to Use After Free with `externref`s

Details:
There is a bug in Wasmtime's code generator, Cranelift, where functions using reference types may be incorrectly missing metadata required for runtime garbage collection (GC). This means that if a GC happens at runtime then the collector will mistakenly think some Wasm stack frames do not have live references to garbage collected values and therefore reclaim and deallocate them. The function can then subsequently continue to use the values, leading later to use-after-free bugs. This bug was introduced in Cranelift's migration to the `regalloc2` register allocator in the Wasmtime 0.37.0 release on 2022-05-20. This bug has been patched and users should upgrade to Wasmtime version 0.38.2.

Mitigations for this issue can be achieved by doing one of:

* Disabling the reference types proposal by passing `false` to [`wasmtime::Config::wasm_reference_types`](https://docs.rs/wasmtime/0.38.0/wasmtime/struct.Config.html#method.wasm_reference_types).
* Downgrading to Wasmtime 0.36.0 or prior.
GitHub Security Advisory: GHSA-99j7-mhfh-w84p
Package: slack-morphism (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-212: Improper Removal of Sensitive Information Before Storage or Transfer, CWE-1258: Exposure of Sensitive System Information Due to Uncleared Debug Information
Vulnerable versions: < 0.41.0
Patched in: 0.41.0

Summary: Slack Morphism for Rust before 0.41.0 can leak Slack OAuth client information in application debug logs

Details:
### Impact
Potential/accidental leaking of Slack OAuth client information in application debug logs.

### Patches
More strict and secure debug formatting was introduced in v0.41 for OAuth secret types to avoid the possibility of printing sensitive information in application logs.

### Workarounds
Don't print/output in logs request and responses for OAuth and client configurations.

### For more information
If you have any questions or comments about this advisory:
* Open an issue in the [repo](https://github.com/abdolence/slack-morphism-rust)
* Email us at [me@abdolence.dev](mailto:me@abdolence.dev)
GitHub Security Advisory: GHSA-735f-pg76-fxc4
Package: openssl-src (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-787: Out-of-bounds Write
Vulnerable versions: >= 300.0.8, < 300.0.9
Patched in: 300.0.9

Summary: openssl-src heap memory corruption with RSA private key operation

Details:
The OpenSSL 3.0.4 release introduced a serious bug in the RSA implementation for X86_64 CPUs supporting the AVX512IFMA instructions. This issue makes the RSA implementation with 2048 bit private keys incorrect on such machines and memory corruption will happen during the computation. As a consequence of the memory corruption an attacker may be able to trigger a remote code execution on the machine performing the computation. SSL/TLS servers or other servers using 2048 bit RSA private keys running on machines supporting AVX512IFMA instructions of the X86_64 architecture are affected by this issue.
GitHub Security Advisory: GHSA-3wx7-46ch-7rq2
Package: openssl-src (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-311: Missing Encryption of Sensitive Data, CWE-326: Inadequate Encryption Strength, CWE-327: Use of a Broken or Risky Cryptographic Algorithm
Vulnerable versions: >= 300.0.0, < 300.0.9
Patched in: 300.0.9

Summary: AES OCB fails to encrypt some bytes

Details:
AES OCB mode for 32-bit x86 platforms using the AES-NI assembly optimized implementation will not encrypt the entirety of the data under some circumstances.  This could reveal sixteen bytes of data that was pre-existing in the memory that wasn't written.  In the special case of "in place" encryption, sixteen bytes of the plaintext would be revealed.

Since OpenSSL does not support OCB based cipher suites for TLS and DTLS, they are both unaffected.
GitHub Security Advisory: GHSA-x4mq-m75f-mx8m
Package: windows (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-820: Missing Synchronization
Vulnerable versions: >= 0.1.2, < 0.32.0
Patched in: 0.32.0

Summary: Delegate functions are missing `Send` bound

Details:
Affected versions of this crate did not require event handlers to have `Send` bound despite there being no guarantee of them being called on any particular thread, which can potentially lead to data races and undefined behavior.

The flaw was corrected in commit [afe3252](https://github.com/microsoft/windows-rs/commit/afe32525c22209aa8f632a0f4ad607863b51796a) by adding `Send` bounds.
GitHub Security Advisory: GHSA-3m6f-3gfg-4x56
Package: simple_asn1 (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: = 0.6.0
Patched in: 0.6.1

Summary: Panic on incorrect date input to `simple_asn1`

Details:
Version 0.6.0 of the `simple_asn1` crate panics on certain malformed
inputs to its parsing functions, including `from_der` and `der_decode`.
Because this crate is frequently used with inputs from the network, this
should be considered a security vulnerability.

The issue occurs when parsing the old ASN.1 "UTCTime" time format.  If an
attacker provides a UTCTime where the first character is ASCII but the
second character is above 0x7f, a string slice operation in the
`from_der_` function will try to slice into the middle of a UTF-8
character, and cause a panic.

This error was introduced in commit
[`d7d39d709577710e9dc8`](https://github.com/acw/simple_asn1/commit/d7d39d709577710e9dc8833ee57d200eef366db8),
which updated `simple_asn1` to use `time` instead of `chrono` because of
[`RUSTSEC-2020-159`](https://rustsec.org/advisories/RUSTSEC-2020-0159).
Versions of `simple_asn1` before 0.6.0 are not affected by this issue.

The [patch](https://github.com/acw/simple_asn1/pull/28) was applied in
`simple_asn1` version 0.6.1.
GitHub Security Advisory: GHSA-67hm-27mx-9cg7
Package: deno (RUST)
Severity: HIGH (CVSS 8.4)
CWE: CWE-59: Improper Link Resolution Before File Access ('Link Following')
Vulnerable versions: < 1.16.0
Patched in: 1.16.0

Summary: Link Following in Deno

Details:
Deno <=1.14.0 file sandbox does not handle symbolic links correctly. When running Deno with specific write access, the Deno.symlink method can be used to gain access to any directory.
GitHub Security Advisory: GHSA-v78m-2q7v-fjqp
Package: rulex (RUST)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-674: Uncontrolled Recursion
Vulnerable versions: < 0.4.3
Patched in: 0.4.3

Summary: Uncontrolled Recursion in rulex

Details:
### Impact
When parsing untrusted rulex expressions, the stack may overflow, possibly enabling a Denial of Service attack. This happens when parsing an expression with several hundred levels of nesting, causing the process to abort immediately.

This is a security concern for you, if
- your service parses untrusted rulex expressions (expressions provided by an untrusted user), and
- your service becomes unavailable when the process running rulex aborts due to a stack overflow.

### Patches
The crash is fixed in version **0.4.3**. Affected users are advised to update to this version.

### Workarounds
None.

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [rulex](https://github.com/rulex-rs/rulex/issues)
* Email me at [ludwig.stecher@gmx.de](mailto:ludwig.stecher@gmx.de)

### Credits

Credit for finding these bugs goes to

- [evanrichter](https://github.com/evanrichter)
- [ForAllSecure Mayhem](https://forallsecure.com/)
- [cargo fuzz](https://github.com/rust-fuzz/cargo-fuzz) and [afl.rs](https://github.com/rust-fuzz/afl.rs)
GitHub Security Advisory: GHSA-8v9w-p43c-r885
Package: rulex (RUST)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-617: Reachable Assertion
Vulnerable versions: < 0.4.3
Patched in: 0.4.3

Summary: Reachable Assertion in rulex

Details:
### Impact
When parsing untrusted rulex expressions, rulex may crash, possibly enabling a Denial of Service attack. This happens when the expression contains a multi-byte UTF-8 code point in a string literal or after a backslash, because rulex tries to slice into the code point and panics as a result.

This is a security concern for you, if
- your service parses untrusted rulex expressions (expressions provided by an untrusted user), and
- your service becomes unavailable when the thread running rulex panics.

### Patches
The crashes are fixed in version **0.4.3**. Affected users are advised to update to this version.

### Workarounds
You can use `catch_unwind` to recover from panics.

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [rulex](https://github.com/rulex-rs/rulex/issues)
* Email me at [ludwig.stecher@gmx.de](mailto:ludwig.stecher@gmx.de)

### Credits

Credit for finding these bugs goes to

- [cargo fuzz](https://github.com/rust-fuzz/cargo-fuzz) and [afl.rs](https://github.com/rust-fuzz/afl.rs)
- [evanrichter](https://github.com/evanrichter)
- [ForAllSecure Mayhem](https://forallsecure.com/)
GitHub Security Advisory: GHSA-83gg-pwxf-jr89
Package: array-macro (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 0.1.2, < 1.0.5
Patched in: 1.0.5

Summary: `array!` macro is unsound in presence of traits that implement methods it calls internally

Details:
Affected versions of this crate called some methods using auto-ref. The affected code looked like this.

```rust
let mut arr = $crate::__core::mem::MaybeUninit::uninit();
let mut vec = $crate::__ArrayVec::<T>::new(arr.as_mut_ptr() as *mut T);
```

In this case, the problem is that `as_mut_ptr` is a method of `&mut MaybeUninit`, not `MaybeUninit`. This made it possible for traits to hijack the method calls in order to cause unsoundness.

```rust
trait AsMutPtr<T> {
    fn as_mut_ptr(&self) -> *mut T;
}
impl<T> AsMutPtr<T> for std::mem::MaybeUninit<T> {
    fn as_mut_ptr(&self) -> *mut T {
        std::ptr::null_mut()
    }
}
array![0; 1];
```

The flaw was corrected by explicitly referencing variables in macro body in order to avoid auto-ref.
GitHub Security Advisory: GHSA-rxhx-9fj6-6h2m
Package: enum-map (RUST)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: >= 2.0.0-2, < 2.0.2
Patched in: 2.0.2

Summary: enum_map macro can cause UB when `Enum` trait is incorrectly implemented

Details:
Affected versions of this crate did not properly check the length of an enum when using `enum_map!` macro, trusting user-provided length.

When the `LENGTH` in the `Enum` trait does not match the array length in the `EnumArray` trait, this can result in the initialization of the enum map with uninitialized types, which in turn can allow an attacker to execute arbitrary code.

This problem can only occur with a manual implementation of the Enum trait, it will never occur for enums that use `#[derive(Enum)]`.

Example code that triggers this vulnerability looks like this:

```rust
enum E {
    A,
    B,
    C,
}

impl Enum for E {
    const LENGTH: usize = 2;

    fn from_usize(value: usize) -> E {
        match value {
            0 => E::A,
            1 => E::B,
            2 => E::C,
            _ => unimplemented!(),
        }
    }

    fn into_usize(self) -> usize {
        self as usize
    }
}

impl<V> EnumArray<V> for E {
    type Array = [V; 3];
}

let _map: EnumMap<E, String> = enum_map! { _ => "Hello, world!".into() };
```

The flaw was corrected in commit [b824e23](https://github.com/xfix/enum-map/commit/b824e232f2fb[PII_REDACTED]0096ac253df8e80dfc) by putting `LENGTH` property on sealed trait for macro to read.
GitHub Security Advisory: GHSA-638m-m8mh-7gw2
Package: openssl-src (RUST)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-327: Use of a Broken or Risky Cryptographic Algorithm
Vulnerable versions: >= 300.0.0, < 300.0.6
Patched in: 300.0.6

Summary: Incorrect MAC key used in the RC4-MD5 ciphersuite

Details:
The OpenSSL 3.0 implementation of the RC4-MD5 ciphersuite incorrectly uses the AAD data as the MAC key. This makes the MAC key trivially predictable. An attacker could exploit this issue by performing a man-in-the-middle attack to modify data being sent from one endpoint to an OpenSSL 3.0 recipient such that the modified data would still pass the MAC integrity check. Note that data sent from an OpenSSL 3.0 endpoint to a non-OpenSSL 3.0 endpoint will always be rejected by the recipient and the connection will fail at that point. Many application protocols require data to be sent from the client to the server first. Therefore, in such a case, only an OpenSSL 3.0 server would be impacted when talking to a non-OpenSSL 3.0 client. If both endpoints are OpenSSL 3.0 then the attacker could modify data being sent in both directions. In this case both clients and servers could be affected, regardless of the application protocol. Note that in the absence of an attacker this bug means that an OpenSSL 3.0 endpoint communicating with a non-OpenSSL 3.0 endpoint will fail to complete the handshake when using this ciphersuite. The confidentiality of data is not impacted by this issue, i.e. an attacker cannot decrypt data that has been encrypted using this ciphersuite - they can only modify it. In order for this attack to work both endpoints must legitimately negotiate the RC4-MD5 ciphersuite. This ciphersuite is not compiled by default in OpenSSL 3.0, and is not available within the default provider or the default ciphersuite list. This ciphersuite will never be used if TLSv1.3 has been negotiated. In order for an OpenSSL 3.0 endpoint to use this ciphersuite the following must have occurred: 1) OpenSSL must have been compiled with the (non-default) compile time option enable-weak-ssl-ciphers 2) OpenSSL must have had the legacy provider explicitly loaded (either through application code or via configuration) 3) The ciphersuite must have been explicitly added to the ciphersuite list 4) The libssl security level must have been set to 0 (default is 1) 5) A version of SSL/TLS below TLSv1.3 must have been negotiated 6) Both endpoints must negotiate the RC4-MD5 ciphersuite in preference to any others that both endpoints have in common Fixed in OpenSSL 3.0.3 (Affected 3.0.0,3.0.1,3.0.2).
GitHub Security Advisory: GHSA-mfm6-r9g2-q4r7
Package: openssl-src (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-295: Improper Certificate Validation
Vulnerable versions: >= 300.0.0, < 300.0.6
Patched in: 300.0.6

Summary: `OCSP_basic_verify` may incorrectly verify the response signing certificate

Details:
The function `OCSP_basic_verify` verifies the signer certificate on an OCSP response. In the case where the (non-default) flag OCSP_NOCHECKS is used then the response will be positive (meaning a successful verification) even in the case where the response signing certificate fails to verify. It is anticipated that most users of `OCSP_basic_verify` will not use the OCSP_NOCHECKS flag. In this case the `OCSP_basic_verify` function will return a negative value (indicating a fatal error) in the case of a certificate verification failure. The normal expected return value in this case would be 0. This issue also impacts the command line OpenSSL "ocsp" application. When verifying an ocsp response with the "-no_cert_checks" option the command line application will report that the verification is successful even though it has in fact failed. In this case the incorrect successful response will also be accompanied by error messages showing the failure and contradicting the apparently successful result. Fixed in OpenSSL 3.0.3 (Affected 3.0.0,3.0.1,3.0.2).
GitHub Security Advisory: GHSA-mmjf-f5jw-w72q
Package: openssl-src (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop')
Vulnerable versions: >= 300.0.0, < 300.0.4
Patched in: 300.0.4

Summary: Invalid handling of `X509_verify_cert()` internal errors in libssl

Details:
Internally libssl in OpenSSL calls X509_verify_cert() on the client side to verify a certificate supplied by a server. That function may return a negative return value to indicate an internal error (for example out of memory). Such a negative return value is mishandled by OpenSSL and will cause an IO function (such as SSL_connect() or SSL_do_handshake()) to not indicate success and a subsequent call to SSL_get_error() to return the value SSL_ERROR_WANT_RETRY_VERIFY. This return value is only supposed to be returned by OpenSSL if the application has previously called SSL_CTX_set_cert_verify_callback(). Since most applications do not do this the SSL_ERROR_WANT_RETRY_VERIFY return value from SSL_get_error() will be totally unexpected and applications may not behave correctly as a result. The exact behaviour will depend on the application but it could result in crashes, infinite loops or other similar incorrect responses. This issue is made more serious in combination with a separate bug in OpenSSL 3.0 that will cause X509_verify_cert() to indicate an internal error when processing a certificate chain. This will occur where a certificate does not include the Subject Alternative Name extension but where a Certificate Authority has enforced name constraints. This issue can occur even with valid chains. By combining the two issues an attacker could induce incorrect, application dependent behaviour. Fixed in OpenSSL 3.0.1 (Affected 3.0.0).