deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-mjv9-vp6w-3rc9
Package: aws-sigv4 (RUST)
Severity: MODERATE (CVSS 5.5)
CWE: CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: = 0.14.0
Patched in: 0.14.1

Summary: AWS SDK for Rust will log AWS credentials when TRACE-level logging is enabled for request sending

Details:
The `aws_sigv4::SigningParams` struct had a derived `Debug` implementation. When debug-formatted, it would include a user's AWS access key, AWS secret key, and security token in plaintext. When TRACE-level logging is enabled for an SDK, `SigningParams` is printed, thereby revealing those credentials to anyone with access to logs.

### Impact
All users of the AWS SDK for Rust who enabled TRACE-level logging, either globally (e.g. `RUST_LOG=trace`), or for the `aws-sigv4` crate specifically.

### Patches
- Versions >= `0.55.1`
- `0.54.2`
- `0.53.2`
- `0.52.1`
- `0.51.1`
- `0.50.1`
- `0.49.1`
- `0.48.1`
- `0.47.1`
- `0.46.1`
- `0.15.1`
- `0.14.1`
- `0.13.1`
- `0.12.1`
- `0.11.1`
- `0.10.2`
- `0.9.1`
- `0.8.1`
- `0.7.1`
- `0.6.1`
- `0.5.3`
- `0.3.1`
- `0.2.1`

### Workarounds
Disable TRACE-level logging for AWS Rust SDK crates.
GitHub Security Advisory: GHSA-mjv9-vp6w-3rc9
Package: aws-sigv4 (RUST)
Severity: MODERATE (CVSS 5.5)
CWE: CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: = 0.15.0
Patched in: 0.15.1

Summary: AWS SDK for Rust will log AWS credentials when TRACE-level logging is enabled for request sending

Details:
The `aws_sigv4::SigningParams` struct had a derived `Debug` implementation. When debug-formatted, it would include a user's AWS access key, AWS secret key, and security token in plaintext. When TRACE-level logging is enabled for an SDK, `SigningParams` is printed, thereby revealing those credentials to anyone with access to logs.

### Impact
All users of the AWS SDK for Rust who enabled TRACE-level logging, either globally (e.g. `RUST_LOG=trace`), or for the `aws-sigv4` crate specifically.

### Patches
- Versions >= `0.55.1`
- `0.54.2`
- `0.53.2`
- `0.52.1`
- `0.51.1`
- `0.50.1`
- `0.49.1`
- `0.48.1`
- `0.47.1`
- `0.46.1`
- `0.15.1`
- `0.14.1`
- `0.13.1`
- `0.12.1`
- `0.11.1`
- `0.10.2`
- `0.9.1`
- `0.8.1`
- `0.7.1`
- `0.6.1`
- `0.5.3`
- `0.3.1`
- `0.2.1`

### Workarounds
Disable TRACE-level logging for AWS Rust SDK crates.
GitHub Security Advisory: GHSA-mjv9-vp6w-3rc9
Package: aws-sigv4 (RUST)
Severity: MODERATE (CVSS 5.5)
CWE: CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: = 0.46.0
Patched in: 0.46.1

Summary: AWS SDK for Rust will log AWS credentials when TRACE-level logging is enabled for request sending

Details:
The `aws_sigv4::SigningParams` struct had a derived `Debug` implementation. When debug-formatted, it would include a user's AWS access key, AWS secret key, and security token in plaintext. When TRACE-level logging is enabled for an SDK, `SigningParams` is printed, thereby revealing those credentials to anyone with access to logs.

### Impact
All users of the AWS SDK for Rust who enabled TRACE-level logging, either globally (e.g. `RUST_LOG=trace`), or for the `aws-sigv4` crate specifically.

### Patches
- Versions >= `0.55.1`
- `0.54.2`
- `0.53.2`
- `0.52.1`
- `0.51.1`
- `0.50.1`
- `0.49.1`
- `0.48.1`
- `0.47.1`
- `0.46.1`
- `0.15.1`
- `0.14.1`
- `0.13.1`
- `0.12.1`
- `0.11.1`
- `0.10.2`
- `0.9.1`
- `0.8.1`
- `0.7.1`
- `0.6.1`
- `0.5.3`
- `0.3.1`
- `0.2.1`

### Workarounds
Disable TRACE-level logging for AWS Rust SDK crates.
GitHub Security Advisory: GHSA-mjv9-vp6w-3rc9
Package: aws-sigv4 (RUST)
Severity: MODERATE (CVSS 5.5)
CWE: CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: = 0.47.0
Patched in: 0.47.1

Summary: AWS SDK for Rust will log AWS credentials when TRACE-level logging is enabled for request sending

Details:
The `aws_sigv4::SigningParams` struct had a derived `Debug` implementation. When debug-formatted, it would include a user's AWS access key, AWS secret key, and security token in plaintext. When TRACE-level logging is enabled for an SDK, `SigningParams` is printed, thereby revealing those credentials to anyone with access to logs.

### Impact
All users of the AWS SDK for Rust who enabled TRACE-level logging, either globally (e.g. `RUST_LOG=trace`), or for the `aws-sigv4` crate specifically.

### Patches
- Versions >= `0.55.1`
- `0.54.2`
- `0.53.2`
- `0.52.1`
- `0.51.1`
- `0.50.1`
- `0.49.1`
- `0.48.1`
- `0.47.1`
- `0.46.1`
- `0.15.1`
- `0.14.1`
- `0.13.1`
- `0.12.1`
- `0.11.1`
- `0.10.2`
- `0.9.1`
- `0.8.1`
- `0.7.1`
- `0.6.1`
- `0.5.3`
- `0.3.1`
- `0.2.1`

### Workarounds
Disable TRACE-level logging for AWS Rust SDK crates.
GitHub Security Advisory: GHSA-mjv9-vp6w-3rc9
Package: aws-sigv4 (RUST)
Severity: MODERATE (CVSS 5.5)
CWE: CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: = 0.48.0
Patched in: 0.48.1

Summary: AWS SDK for Rust will log AWS credentials when TRACE-level logging is enabled for request sending

Details:
The `aws_sigv4::SigningParams` struct had a derived `Debug` implementation. When debug-formatted, it would include a user's AWS access key, AWS secret key, and security token in plaintext. When TRACE-level logging is enabled for an SDK, `SigningParams` is printed, thereby revealing those credentials to anyone with access to logs.

### Impact
All users of the AWS SDK for Rust who enabled TRACE-level logging, either globally (e.g. `RUST_LOG=trace`), or for the `aws-sigv4` crate specifically.

### Patches
- Versions >= `0.55.1`
- `0.54.2`
- `0.53.2`
- `0.52.1`
- `0.51.1`
- `0.50.1`
- `0.49.1`
- `0.48.1`
- `0.47.1`
- `0.46.1`
- `0.15.1`
- `0.14.1`
- `0.13.1`
- `0.12.1`
- `0.11.1`
- `0.10.2`
- `0.9.1`
- `0.8.1`
- `0.7.1`
- `0.6.1`
- `0.5.3`
- `0.3.1`
- `0.2.1`

### Workarounds
Disable TRACE-level logging for AWS Rust SDK crates.
GitHub Security Advisory: GHSA-mjv9-vp6w-3rc9
Package: aws-sigv4 (RUST)
Severity: MODERATE (CVSS 5.5)
CWE: CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: = 0.49.0
Patched in: 0.49.1

Summary: AWS SDK for Rust will log AWS credentials when TRACE-level logging is enabled for request sending

Details:
The `aws_sigv4::SigningParams` struct had a derived `Debug` implementation. When debug-formatted, it would include a user's AWS access key, AWS secret key, and security token in plaintext. When TRACE-level logging is enabled for an SDK, `SigningParams` is printed, thereby revealing those credentials to anyone with access to logs.

### Impact
All users of the AWS SDK for Rust who enabled TRACE-level logging, either globally (e.g. `RUST_LOG=trace`), or for the `aws-sigv4` crate specifically.

### Patches
- Versions >= `0.55.1`
- `0.54.2`
- `0.53.2`
- `0.52.1`
- `0.51.1`
- `0.50.1`
- `0.49.1`
- `0.48.1`
- `0.47.1`
- `0.46.1`
- `0.15.1`
- `0.14.1`
- `0.13.1`
- `0.12.1`
- `0.11.1`
- `0.10.2`
- `0.9.1`
- `0.8.1`
- `0.7.1`
- `0.6.1`
- `0.5.3`
- `0.3.1`
- `0.2.1`

### Workarounds
Disable TRACE-level logging for AWS Rust SDK crates.
GitHub Security Advisory: GHSA-mjv9-vp6w-3rc9
Package: aws-sigv4 (RUST)
Severity: MODERATE (CVSS 5.5)
CWE: CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: = 0.51.0
Patched in: 0.51.1

Summary: AWS SDK for Rust will log AWS credentials when TRACE-level logging is enabled for request sending

Details:
The `aws_sigv4::SigningParams` struct had a derived `Debug` implementation. When debug-formatted, it would include a user's AWS access key, AWS secret key, and security token in plaintext. When TRACE-level logging is enabled for an SDK, `SigningParams` is printed, thereby revealing those credentials to anyone with access to logs.

### Impact
All users of the AWS SDK for Rust who enabled TRACE-level logging, either globally (e.g. `RUST_LOG=trace`), or for the `aws-sigv4` crate specifically.

### Patches
- Versions >= `0.55.1`
- `0.54.2`
- `0.53.2`
- `0.52.1`
- `0.51.1`
- `0.50.1`
- `0.49.1`
- `0.48.1`
- `0.47.1`
- `0.46.1`
- `0.15.1`
- `0.14.1`
- `0.13.1`
- `0.12.1`
- `0.11.1`
- `0.10.2`
- `0.9.1`
- `0.8.1`
- `0.7.1`
- `0.6.1`
- `0.5.3`
- `0.3.1`
- `0.2.1`

### Workarounds
Disable TRACE-level logging for AWS Rust SDK crates.
GitHub Security Advisory: GHSA-mjv9-vp6w-3rc9
Package: aws-sigv4 (RUST)
Severity: MODERATE (CVSS 5.5)
CWE: CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: = 0.52.0
Patched in: 0.52.1

Summary: AWS SDK for Rust will log AWS credentials when TRACE-level logging is enabled for request sending

Details:
The `aws_sigv4::SigningParams` struct had a derived `Debug` implementation. When debug-formatted, it would include a user's AWS access key, AWS secret key, and security token in plaintext. When TRACE-level logging is enabled for an SDK, `SigningParams` is printed, thereby revealing those credentials to anyone with access to logs.

### Impact
All users of the AWS SDK for Rust who enabled TRACE-level logging, either globally (e.g. `RUST_LOG=trace`), or for the `aws-sigv4` crate specifically.

### Patches
- Versions >= `0.55.1`
- `0.54.2`
- `0.53.2`
- `0.52.1`
- `0.51.1`
- `0.50.1`
- `0.49.1`
- `0.48.1`
- `0.47.1`
- `0.46.1`
- `0.15.1`
- `0.14.1`
- `0.13.1`
- `0.12.1`
- `0.11.1`
- `0.10.2`
- `0.9.1`
- `0.8.1`
- `0.7.1`
- `0.6.1`
- `0.5.3`
- `0.3.1`
- `0.2.1`

### Workarounds
Disable TRACE-level logging for AWS Rust SDK crates.
GitHub Security Advisory: GHSA-mjv9-vp6w-3rc9
Package: aws-sigv4 (RUST)
Severity: MODERATE (CVSS 5.5)
CWE: CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: = 0.53.1
Patched in: 0.53.2

Summary: AWS SDK for Rust will log AWS credentials when TRACE-level logging is enabled for request sending

Details:
The `aws_sigv4::SigningParams` struct had a derived `Debug` implementation. When debug-formatted, it would include a user's AWS access key, AWS secret key, and security token in plaintext. When TRACE-level logging is enabled for an SDK, `SigningParams` is printed, thereby revealing those credentials to anyone with access to logs.

### Impact
All users of the AWS SDK for Rust who enabled TRACE-level logging, either globally (e.g. `RUST_LOG=trace`), or for the `aws-sigv4` crate specifically.

### Patches
- Versions >= `0.55.1`
- `0.54.2`
- `0.53.2`
- `0.52.1`
- `0.51.1`
- `0.50.1`
- `0.49.1`
- `0.48.1`
- `0.47.1`
- `0.46.1`
- `0.15.1`
- `0.14.1`
- `0.13.1`
- `0.12.1`
- `0.11.1`
- `0.10.2`
- `0.9.1`
- `0.8.1`
- `0.7.1`
- `0.6.1`
- `0.5.3`
- `0.3.1`
- `0.2.1`

### Workarounds
Disable TRACE-level logging for AWS Rust SDK crates.
GitHub Security Advisory: GHSA-mjv9-vp6w-3rc9
Package: aws-sigv4 (RUST)
Severity: MODERATE (CVSS 5.5)
CWE: CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: = 0.54.1
Patched in: 0.54.2

Summary: AWS SDK for Rust will log AWS credentials when TRACE-level logging is enabled for request sending

Details:
The `aws_sigv4::SigningParams` struct had a derived `Debug` implementation. When debug-formatted, it would include a user's AWS access key, AWS secret key, and security token in plaintext. When TRACE-level logging is enabled for an SDK, `SigningParams` is printed, thereby revealing those credentials to anyone with access to logs.

### Impact
All users of the AWS SDK for Rust who enabled TRACE-level logging, either globally (e.g. `RUST_LOG=trace`), or for the `aws-sigv4` crate specifically.

### Patches
- Versions >= `0.55.1`
- `0.54.2`
- `0.53.2`
- `0.52.1`
- `0.51.1`
- `0.50.1`
- `0.49.1`
- `0.48.1`
- `0.47.1`
- `0.46.1`
- `0.15.1`
- `0.14.1`
- `0.13.1`
- `0.12.1`
- `0.11.1`
- `0.10.2`
- `0.9.1`
- `0.8.1`
- `0.7.1`
- `0.6.1`
- `0.5.3`
- `0.3.1`
- `0.2.1`

### Workarounds
Disable TRACE-level logging for AWS Rust SDK crates.
GitHub Security Advisory: GHSA-mjv9-vp6w-3rc9
Package: aws-sigv4 (RUST)
Severity: MODERATE (CVSS 5.5)
CWE: CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: = 0.55.0
Patched in: 0.55.1

Summary: AWS SDK for Rust will log AWS credentials when TRACE-level logging is enabled for request sending

Details:
The `aws_sigv4::SigningParams` struct had a derived `Debug` implementation. When debug-formatted, it would include a user's AWS access key, AWS secret key, and security token in plaintext. When TRACE-level logging is enabled for an SDK, `SigningParams` is printed, thereby revealing those credentials to anyone with access to logs.

### Impact
All users of the AWS SDK for Rust who enabled TRACE-level logging, either globally (e.g. `RUST_LOG=trace`), or for the `aws-sigv4` crate specifically.

### Patches
- Versions >= `0.55.1`
- `0.54.2`
- `0.53.2`
- `0.52.1`
- `0.51.1`
- `0.50.1`
- `0.49.1`
- `0.48.1`
- `0.47.1`
- `0.46.1`
- `0.15.1`
- `0.14.1`
- `0.13.1`
- `0.12.1`
- `0.11.1`
- `0.10.2`
- `0.9.1`
- `0.8.1`
- `0.7.1`
- `0.6.1`
- `0.5.3`
- `0.3.1`
- `0.2.1`

### Workarounds
Disable TRACE-level logging for AWS Rust SDK crates.
GitHub Security Advisory: GHSA-qvc4-78gw-pv8p
Package: enumflags2 (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 0.7.0, < 0.7.7
Patched in: 0.7.7

Summary: Adverserial use of `make_bitflags!` macro can cause undefined behavior

Details:
The macro relied on an expression of the form `Enum::Variant` always being a
variant of the enum. However, it may also be an associated integer constant, in
which case there's no guarantee that the value of said constant consists only of
bits valid for this bitflag type.

Thus, code like this could create an invalid `BitFlags<Test>`, which would cause
iterating over it to trigger undefined behavior. As the debug formatter
internally iterates over the value, it is also affected.

```rust
use enumflags2::{bitflags, make_bitflags};

#[bitflags]
#[repr(u8)]
#[derive(Copy, Clone, Debug)]
enum Test {
    A = 1,
    B = 2,
}

impl Test {
    const C: u8 = 69;
}

fn main() {
    let x = make_bitflags!(Test::{C});
    // printing or iterating over x is UB
}
```
GitHub Security Advisory: GHSA-f8vr-r385-rh5r
Package: h2 (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 0.3.17
Patched in: 0.3.17

Summary: h2 vulnerable to denial of service

Details:
Hyper is an HTTP library for Rust and h2 is an HTTP 2.0 client & server implementation for Rust. An issue was discovered in h2 v0.2.4 when processing header frames. It incorrectly processes the HTTP2 `RST_STREAM` frames by not always releasing the memory immediately upon receiving the reset frame, leading to stream stacking. As a result, the memory and CPU usage are high which can lead to a Denial of Service (DoS).

This issue affects users only when dealing with http2 connections.
GitHub Security Advisory: GHSA-fq33-vmhv-48xh
Package: ntru (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 0.4.3, <= 0.5.6
Patched in: unpatched

Summary: ntru-rs has unsound FFI: Wrong API usage causes write past allocated area

Details:
The following usage causes undefined behavior.
```rust
let kp: ntru::types::KeyPair = …;
kp.get_public().export(Default::default())
```

When compiled with debug assertions, the code above will trigger a `attempt to subtract with overflow` panic before UB occurs.
Other mistakes (e.g. using `EncParams` from a different key) may always trigger UB.

Likely, older versions of this crate are also affected, but have not been tested.
GitHub Security Advisory: GHSA-2qv5-7mw5-j3cg
Package: spin (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 0.9.3, < 0.9.8
Patched in: 0.9.8

Summary: spin-rs initialisation failure in `Once::try_call_once` can lead to undefined behaviour for other initialisers

Details:
`Once::try_call_once` is unsound if invoked more than once concurrently and any call fails to initialise successfully.
GitHub Security Advisory: GHSA-v5w6-wcm8-jm4q
Package: openssl-src (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-415: Double Free
Vulnerable versions: >= 300.0.0, < 300.0.12
Patched in: 300.0.12

Summary: openssl-src contains Double free after calling `PEM_read_bio_ex`

Details:
The function `PEM_read_bio_ex()` reads a PEM file from a BIO and parses and decodes the "name" (e.g. "CERTIFICATE"), any header data and the payload data. If the function succeeds then the "name_out", "header" and "data" arguments are populated with pointers to buffers containing the relevant decoded data. The caller is responsible for freeing those buffers. It is possible to construct a PEM file that results in 0 bytes of payload data. In this case `PEM_read_bio_ex()` will return a failure code but will populate the header argument with a pointer to a buffer that has already been freed. If the caller also frees this buffer then a double free will occur. This will most likely lead to a crash. This could be exploited by an attacker who has the ability to supply malicious PEM files for parsing to achieve a denial of service attack.

The functions `PEM_read_bio()` and `PEM_read()` are simple wrappers around `PEM_read_bio_ex()` and therefore these functions are also directly affected.

These functions are also called indirectly by a number of other OpenSSL functions including `PEM_X509_INFO_read_bio_ex()` and
`SSL_CTX_use_serverinfo_file()` which are also vulnerable. Some OpenSSL internal uses of these functions are not vulnerable because the caller does not free the header argument if `PEM_read_bio_ex()` returns a failure code. These locations include the `PEM_read_bio_TYPE()` functions as well as the decoders introduced in OpenSSL 3.0.
GitHub Security Advisory: GHSA-v5w6-wcm8-jm4q
Package: openssl-src (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-415: Double Free
Vulnerable versions: < 111.25.0
Patched in: 111.25.0

Summary: openssl-src contains Double free after calling `PEM_read_bio_ex`

Details:
The function `PEM_read_bio_ex()` reads a PEM file from a BIO and parses and decodes the "name" (e.g. "CERTIFICATE"), any header data and the payload data. If the function succeeds then the "name_out", "header" and "data" arguments are populated with pointers to buffers containing the relevant decoded data. The caller is responsible for freeing those buffers. It is possible to construct a PEM file that results in 0 bytes of payload data. In this case `PEM_read_bio_ex()` will return a failure code but will populate the header argument with a pointer to a buffer that has already been freed. If the caller also frees this buffer then a double free will occur. This will most likely lead to a crash. This could be exploited by an attacker who has the ability to supply malicious PEM files for parsing to achieve a denial of service attack.

The functions `PEM_read_bio()` and `PEM_read()` are simple wrappers around `PEM_read_bio_ex()` and therefore these functions are also directly affected.

These functions are also called indirectly by a number of other OpenSSL functions including `PEM_X509_INFO_read_bio_ex()` and
`SSL_CTX_use_serverinfo_file()` which are also vulnerable. Some OpenSSL internal uses of these functions are not vulnerable because the caller does not free the header argument if `PEM_read_bio_ex()` returns a failure code. These locations include the `PEM_read_bio_TYPE()` functions as well as the decoders introduced in OpenSSL 3.0.
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: < 111.22.0
Patched in: 111.22.0

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-vc5p-j8vw-mc6x
Package: pleaser (RUST)
Severity: HIGH (CVSS 7.8)
CWE: CWE-269: Improper Privilege Management, CWE-279: Incorrect Execution-Assigned Permissions
Vulnerable versions: < 0.4.0
Patched in: 0.4.0

Summary: Permissions bypass in pleaser

Details:
Failure to normalize the umask in pleaser before 0.4.0 allows a local attacker to gain full root privileges if they are allowed to execute at least one command.
GitHub Security Advisory: GHSA-5ww6-px42-wc85
Package: openssl-src (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
Vulnerable versions: < 111.16.0
Patched in: 111.16.0

Summary: SM2 Decryption Buffer Overflow

Details:
In order to decrypt SM2 encrypted data an application is expected to call the API function EVP_PKEY_decrypt(). Typically an application will call this function twice. The first time, on entry, the "out" parameter can be NULL and, on exit, the "outlen" parameter is populated with the buffer size required to hold the decrypted plaintext. The application can then allocate a sufficiently sized buffer and call EVP_PKEY_decrypt() again, but this time passing a non-NULL value for the "out" parameter. A bug in the implementation of the SM2 decryption code means that the calculation of the buffer size required to hold the plaintext returned by the first call to EVP_PKEY_decrypt() can be smaller than the actual size required by the second call. This can lead to a buffer overflow when EVP_PKEY_decrypt() is called by the application a second time with a buffer that is too small. A malicious attacker who is able present SM2 content for decryption to an application could cause attacker chosen data to overflow the buffer by up to a maximum of 62 bytes altering the contents of other data held after the buffer, possibly changing application behaviour or causing the application to crash. The location of the buffer is application dependent but is typically heap allocated. Fixed in OpenSSL 1.1.1l (Affected 1.1.1-1.1.1k).
GitHub Security Advisory: GHSA-vp68-2wrm-69qm
Package: matrix-sdk-crypto (RUST)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-287: Improper Authentication
Vulnerable versions: < 0.6.0
Patched in: 0.6.0

Summary: matrix-sdk-crypto contains potential impersonation via room key forward responses

Details:
### Impact

When matrix-rust-sdk before 0.6 requests a room key from our devices, it correctly accepts key forwards only if they are a response to a previous request. However, it doesn't check that the device that responded matches the device the key was requested from.

This allows a malicious homeserver to insert room keys of questionable validity into the key store in some situations, potentially assisting in an impersonation attack. Note that even if key injection succeeds in this way, all forwarded keys have the `imported` flag set, which is used as an indicator that such keys have lesser authentication properties (and should be marked as such in clients, e.g. with a grey shield besides the message).

### For more information
If you have any questions or comments about this advisory, e-mail us at [security@matrix.org](mailto:security@matrix.org).
GitHub Security Advisory: GHSA-84rm-qf37-fgc2
Package: openssl-src (RUST)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-190: Integer Overflow or Wraparound, CWE-476: NULL Pointer Dereference
Vulnerable versions: < 111.14.0
Patched in: 111.14.0

Summary: Integer Overflow in openssl-src

Details:
Calls to EVP_CipherUpdate, EVP_EncryptUpdate and EVP_DecryptUpdate may overflow the output length argument in some cases where the input length is close to the maximum permissable length for an integer on the platform. In such cases the return value from the function call will be 1 (indicating success), but the output length value will be negative. This could cause applications to behave incorrectly or crash. OpenSSL versions 1.1.1i and below are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1j. OpenSSL versions 1.0.2x and below are affected by this issue. However OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2y. Other users should upgrade to 1.1.1j. Fixed in OpenSSL 1.1.1j (Affected 1.1.1-1.1.1i). Fixed in OpenSSL 1.0.2y (Affected 1.0.2-1.0.2x).