Vulnerability dependency `frame-benchmarking-cli`

[chungquantin]

By adding a benchmarking feature in #424, we need to add frame-benchmarking-cli@v46.0.0 crate which introduces a lot of vulnerabilities detected by cargo deny. This issue gathers all the vulnerabilities related to the mentioned crate.

Reasons why we can't resolve below vulnerabilities because v46.0.0 is the latest version so no upgrade available.

[chungquantin]

• Advisories: https://rustsec.org/advisories/RUSTSEC-2024-0336

Summary

[advisory]
id = "RUSTSEC-2024-0336"
package = "rustls"
date = "2024-04-19"
url = "https://github.com/rustls/rustls/security/advisories/GHSA-6g7w-8wpp-frhj"
categories = ["denial-of-service"]
aliases = ["CVE-2024-32650", "GHSA-6g7w-8wpp-frhj"]
cvss = "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"

[versions]
patched = [">= 0.23.5", ">= 0.22.4, < 0.23.0", ">= 0.21.11, < 0.22.0"]

[affected]
functions = { "rustls::ConnectionCommon::complete_io" = ["<= 0.23.4", "<= 0.22.3", "<= 0.21.10", "0.20"] }

rustls::ConnectionCommon::complete_io could fall into an infinite loop based on network input

If a close_notify alert is received during a handshake, complete_io
does not terminate.

Callers which do not call complete_io are not affected.

rustls-tokio and rustls-ffi do not call complete_io
and are not affected.

rustls::Stream and rustls::StreamOwned types use
complete_io and are affected.

[chungquantin]

• Advisories: https://rustsec.org/advisories/RUSTSEC-2024-0421.html

Summary

[advisory]
id = "RUSTSEC-2024-0421"

package = "idna"

date = "2024-12-09"

categories = ["privilege-escalation"]

keywords = ["idna", "punycode", "same-origin", "domain-name"]

aliases = ["CVE-2024-12224"]

url = "https://bugzilla.mozilla.org/show_bug.cgi?id=1887898"

[versions]
patched = [">= 1.0.0"]

idna accepts Punycode labels that do not produce any non-ASCII when decoded

idna 0.5.0 and earlier accepts Punycode labels that do not produce any non-ASCII output, which means that either ASCII labels or the empty root label can be masked such that they appear unequal without IDNA processing or when processed with a different implementation and equal when processed with idna 0.5.0 or earlier.

Concretely, example.org and xn--example-.org become equal after processing by idna 0.5.0 or earlier. Also, example.org.xn-- and example.org. become equal after processing by idna 0.5.0 or earlier.

In applications using idna (but not in idna itself) this may be able to lead to privilege escalation when host name comparison is part of a privilege check and the behavior is combined with a client that resolves domains with such labels instead of treating them as errors that preclude DNS resolution / URL fetching and with the attacker managing to introduce a DNS entry (and TLS certificate) for an xn---masked name that turns into the name of the target when processed by idna 0.5.0 or earlier.

Remedy

Upgrade to idna 1.0.3 or later, if depending on idna directly, or to url 2.5.4 or later, if depending on idna via url. (This issue was fixed in idna 1.0.0, but versions earlier than 1.0.3 are not recommended for other reasons.)

When upgrading, please take a moment to read about alternative Unicode back ends for idna.

If you are using Rust earlier than 1.81 in combination with SQLx 0.8.2 or earlier, please also read an issue about combining them with url 2.5.4 and idna 1.0.3.

Additional information

This issue resulted from idna 0.5.0 and earlier implementing the UTS 46 specification literally on this point and the specification having this bug. The specification bug has been fixed in revision 33 of UTS 46.

Acknowledgements

Thanks to kageshiron for recognizing the security implications of this behavior.

[chungquantin]

• Advisories: https://rustsec.org/advisories/RUSTSEC-2025-0009.html

Summary

[advisory]
id = "RUSTSEC-2025-0009"
package = "ring"
date = "2025-03-06"
url = "https://github.com/briansmith/ring/blob/main/RELEASES.md#version-01712-2025-03-05"
categories = ["denial-of-service"]

[versions]
patched = [">= 0.17.12"]
unaffected = []

Some AES functions may panic when overflow checking is enabled.

ring::aead::quic::HeaderProtectionKey::new_mask() may panic when overflow
checking is enabled. In the QUIC protocol, an attacker can induce this panic by
sending a specially-crafted packet. Even unintentionally it is likely to occur
in 1 out of every 2**32 packets sent and/or received.

On 64-bit targets operations using ring::aead::{AES_128_GCM, AES_256_GCM} may
panic when overflow checking is enabled, when encrypting/decrypting approximately
68,719,476,700 bytes (about 64 gigabytes) of data in a single chunk. Protocols
like TLS and SSH are not affected by this because those protocols break large
amounts of data into small chunks. Similarly, most applications will not
attempt to encrypt/decrypt 64GB of data in one chunk.

Overflow checking is not enabled in release mode by default, but
RUSTFLAGS="-C overflow-checks" or overflow-checks = true in the Cargo.toml
profile can override this. Overflow checking is usually enabled by default in
debug mode.

[chungquantin]

• Advisories: https://rustsec.org/advisories/RUSTSEC-2025-0010

Summary

[advisory]
id = "RUSTSEC-2025-0010"
package = "ring"
date = "2025-03-05"
informational = "unmaintained"
url = "https://github.com/briansmith/ring/discussions/2450"

[versions]
patched = []
unaffected = [ ">= 0.17" ]

Versions of ring prior to 0.17 are unmaintained.

ring 0.16.20 was released over 4 years ago and isn't maintained, tested, etc.

Additionally, the project's general policy is to only patch the latest release,
which is 0.17.12 now. It will be difficult for anybody to backport future fixes
to versions earlier than 0.17.10 due to license changes.

[chungquantin]

• Advisories: https://rustsec.org/advisories/RUSTSEC-2024-0370.html

Summary

[advisory]
id = "RUSTSEC-2024-0370"
package = "proc-macro-error"
date = "2024-09-01"
informational = "unmaintained"
url = "https://gitlab.com/CreepySkeleton/proc-macro-error/-/issues/20"

[versions]
patched = []

proc-macro-error is unmaintained

proc-macro-error's maintainer seems to be unreachable, with no commits for 2 years, no releases pushed for 4 years, and no activity on the GitLab repo or response to email.

proc-macro-error also depends on syn 1.x, which may be bringing duplicate dependencies into dependant build trees.

Possible Alternative(s)

• manyhow
• proc-macro-error2
• proc-macro2-diagnostics

[chungquantin]

• Advisories: https://rustsec.org/advisories/RUSTSEC-2022-0061.html

Summary

[advisory]
id = "RUSTSEC-2022-0061"
package = "parity-wasm"
date = "2022-10-01"
url = "https://github.com/paritytech/parity-wasm/pull/334"
informational = "unmaintained"

[versions]
patched = []

Crate parity-wasm deprecated by the author

This PR explicitly deprecates parity-wasm.
The author recommends switching to wasm-tools.

[chungquantin]

• Advisories: https://rustsec.org/advisories/RUSTSEC-2020-0168.html

Summary

[advisory]
id = "RUSTSEC-2020-0168"
package = "mach"
date = "2020-07-14"
url = "https://github.com/fitzgen/mach/issues/63"
informational = "unmaintained"

[versions]
patched = []

mach is unmaintained

Last release was almost 4 years ago.

Maintainer(s) seem to be completely unreachable.

Possible Alternative(s)

These may or may not be suitable alternatives and have not been vetted in any way;

• mach2 - direct fork

[chungquantin]

• Advisories: https://rustsec.org/advisories/RUSTSEC-2025-0017.html

Summary

[advisory]
id = "RUSTSEC-2025-0017"
package = "trust-dns-proto"
date = "2025-03-23"
url = "https://crates.io/crates/hickory-proto"
informational = "unmaintained"
references = ["https://github.com/hickory-dns/hickory-dns/issues/2051"]

[versions]
patched = []
unaffected = ["<= 0.23.0"]

The trust-dns project has been rebranded to hickory-dns

The trust-dns-proto crate is now available as hickory-proto.

[AlexD10S]

Advisory: https://rustsec.org/advisories/RUSTSEC-2024-0438

Wasmtime doesn't fully sandbox all the Windows device filenames

ID: RUSTSEC-2024-0438
     ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2024-0438
     ├ This is an entry in the RustSec database for the Wasmtime security advisory
       located at
       https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-c2f5-jxjv-2hh8.
       For more information see the GitHub-hosted security advisory.
     ├ Announcement: https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-c2f5-jxjv-2hh8
     ├ Solution: Upgrade to >=24.0.2, <25.0.0 OR >=25.0.3, <26.0.0 OR >=26.0.1 (try `cargo update -p wasmtime`)

[AlexD10S]

Advisory: https://rustsec.org/advisories/RUSTSEC-2023-0091

Miscompilation of wasm i64x2.shr_s instruction with constant input on x86_64

 ID: RUSTSEC-2023-0091
     ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2023-0091
     ├ This is an entry in the RustSec database for the Wasmtime security advisory
       located at
       https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-gw5p-q8mj-p7gh.
       For more information see the GitHub-hosted security advisory.
     ├ Announcement: https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-gw5p-q8mj-p7gh
     ├ Solution: Upgrade to >=10.0.2, <11.0.0 OR >=11.0.2, <12.0.0 OR >=12.0.2 (try `cargo update -p wasmtime`)

[chungquantin]

Advisory: https://rustsec.org/advisories/RUSTSEC-2024-0442.html

[advisory]
id = "RUSTSEC-2024-0442"
package = "wasmtime-jit-debug"
date = "2024-07-06"
url = "https://github.com/bytecodealliance/wasmtime/issues/8905"
informational = "unsound"
categories = ["memory-exposure"]

[affected]
functions = { "wasmtime_jit_debug::perf_jitdump::JitDumpFile::dump_code_load_record" = ["<= 24.0.0"] }

[versions]
patched = [">= 24.0.0"]

Dump Undefined Memory by JitDumpFile

The unsound function dump_code_load_record uses from_raw_parts to directly convert
the pointer addr and len into a slice without any validation and that memory block
would be dumped.

Thus, the 'safe' function dump_code_load_record is actually 'unsafe' since it requires
the caller to guarantee that the addr is valid and len must not overflow.
Otherwise, the function could dump the memory into file illegally, causing memory leak.

Note: this is an internal-only crate in the Wasmtime project not intended for
external use and is more strongly signaled nowadays as of
bytecodealliance/wasmtime#10963.
Please open an issue in Wasmtime if you're using this crate directly.

[AlexD10S]

Advisory: https://rustsec.org/advisories/RUSTSEC-2025-0057

fxhash - no longer maintained

The fxhash crate is no longer maintained.

The repository is stale and owner is no longer active on GitHub

[AlexD10S]

Advisory: https://rustsec.org/advisories/RUSTSEC-2025-0056

adler crate is unmaintained, use adler2 instead

The adler crate is no longer actively maintained. If you rely on this crate, consider switching to a maintained alternative.