Vulnerabilities

RUSTSEC-2024-0332

Degradation of service in h2 servers with CONTINUATION Flood

An attacker can send a flood of CONTINUATION frames, causing h2 to process them indefinitely.
This results in an increase in CPU usage.

Tokio task budget helps prevent this from a complete denial-of-service, as the server can still
respond to legitimate requests, albeit with increased latency.

More details at "https://seanmonstar.com/blog/hyper-http2-continuation-flood/.

Patches available for 0.4.x and 0.3.x versions.

RUSTSEC-2024-0003

Resource exhaustion vulnerability in h2 may lead to Denial of Service (DoS)

An attacker with an HTTP/2 connection to an affected endpoint can send a steady stream of invalid frames to force the
generation of reset frames on the victim endpoint.
By closing their recv window, the attacker could then force these resets to be queued in an unbounded fashion,
resulting in Out Of Memory (OOM) and high CPU usage.

This fix is corrected in hyperium/h2#737, which limits the total number of
internal error resets emitted by default before the connection is closed.

RUSTSEC-2024-0421

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.

RUSTSEC-2025-0022

Use-After-Free in Md::fetch and Cipher::fetch

When a Some(...) value was passed to the properties argument of either of these functions, a use-after-free would result.

In practice this would nearly always result in OpenSSL treating the properties as an empty string (due to CString::drop's behavior).

The maintainers thank quitbug for reporting this vulnerability to us.

RUSTSEC-2024-0357

MemBio::get_buf has undefined behavior with empty buffers

Previously, MemBio::get_buf called slice::from_raw_parts with a null-pointer, which violates the functions invariants, leading to undefined behavior. In debug builds this would produce an assertion failure. This is now fixed.

RUSTSEC-2025-0004

ssl::select_next_proto use after free

In openssl versions before 0.10.70, ssl::select_next_proto can return a slice pointing into the server argument's buffer but with a lifetime bound to the client argument. In situations where the server buffer's lifetime is shorter than the client buffer's, this can cause a use after free. This could cause the server to crash or to return arbitrary memory contents to the client.

openssl 0.10.70 fixes the signature of ssl::select_next_proto to properly constrain the output buffer's lifetime to that of both input buffers.

In standard usage of ssl::select_next_proto in the callback passed to SslContextBuilder::set_alpn_select_callback, code is only affected if the server buffer is constructed within the callback. For example:

Not vulnerable - the server buffer has a 'static lifetime:

builder.set_alpn_select_callback(|_, client_protos| {
    ssl::select_next_proto(b"\x02h2", client_protos).ok_or_else(AlpnError::NOACK)
});

Not vulnerable - the server buffer outlives the handshake:

let server_protos = b"\x02h2".to_vec();
builder.set_alpn_select_callback(|_, client_protos| {
    ssl::select_next_proto(&server_protos, client_protos).ok_or_else(AlpnError::NOACK)
});

Vulnerable - the server buffer is freed when the callback returns:

builder.set_alpn_select_callback(|_, client_protos| {
    let server_protos = b"\x02h2".to_vec();
    ssl::select_next_proto(&server_protos, client_protos).ok_or_else(AlpnError::NOACK)
});

Warnings

RUSTSEC-2024-0413

gtk-rs GTK3 bindings - no longer maintained

The gtk-rs GTK3 bindings are no longer maintained.

The maintainers have archived the repository, and added a note to the crate
description and its README.md that the crates are no longer maintained.

Please take a look at gtk4-rs instead.

### [RUSTSEC-2024-0416](https://rustsec.org/advisories/RUSTSEC-2024-0416.html)

> gtk-rs GTK3 bindings - no longer maintained

| Details             |                                                |
| ------------------- | ---------------------------------------------- |
| Status              | unmaintained                |
| Package             | `atk-sys`                      |
| Version             | `0.15.1`                   |
| URL                 | [https://github.com/gtk-rs/gtk3-rs/commit/508a69b63a3c5bf73790e0e59101a955847f30d6](https://github.com/gtk-rs/gtk3-rs/commit/508a69b63a3c5bf73790e0e59101a955847f30d6) |
| Date                | 2024-03-04                         |

The gtk-rs GTK3 bindings are no longer maintained.

The maintainers have archived the repository, and added a note to the crate
description and its README.md that the crates are no longer maintained.

Please take a look at [gtk4-rs](https://github.com/gtk-rs/gtk4-rs) instead.

RUSTSEC-2024-0375

atty is unmaintained

The maintainer of atty has published an official notice that the crate is no longer
under development, and that users should instead rely on the functionality in the standard library's IsTerminal trait.

Alternative(s)

• std::io::IsTerminal - Stable since Rust 1.70.0 and the recommended replacement per the atty maintainer.
• is-terminal - Standalone crate supporting Rust older than 1.70.0

RUSTSEC-2024-0388

derivative is unmaintained; consider using an alternative

The derivative crate is no longer maintained.
Consider using any alternative, for instance:

• derive_more
• derive-where
• educe

RUSTSEC-2024-0412

gtk-rs GTK3 bindings - no longer maintained

The gtk-rs GTK3 bindings are no longer maintained.

The maintainers have archived the repository, and added a note to the crate
description and its README.md that the crates are no longer maintained.

Please take a look at gtk4-rs instead.

### [RUSTSEC-2024-0418](https://rustsec.org/advisories/RUSTSEC-2024-0418.html)

> gtk-rs GTK3 bindings - no longer maintained

| Details             |                                                |
| ------------------- | ---------------------------------------------- |
| Status              | unmaintained                |
| Package             | `gdk-sys`                      |
| Version             | `0.15.1`                   |
| URL                 | [https://github.com/gtk-rs/gtk3-rs/commit/508a69b63a3c5bf73790e0e59101a955847f30d6](https://github.com/gtk-rs/gtk3-rs/commit/508a69b63a3c5bf73790e0e59101a955847f30d6) |
| Date                | 2024-03-04                         |

The gtk-rs GTK3 bindings are no longer maintained.

The maintainers have archived the repository, and added a note to the crate
description and its README.md that the crates are no longer maintained.

Please take a look at [gtk4-rs](https://github.com/gtk-rs/gtk4-rs) instead.

RUSTSEC-2024-0411

gtk-rs GTK3 bindings - no longer maintained

The gtk-rs GTK3 bindings are no longer maintained.

The maintainers have archived the repository, and added a note to the crate
description and its README.md that the crates are no longer maintained.

Please take a look at gtk4-rs instead.

### [RUSTSEC-2024-0414](https://rustsec.org/advisories/RUSTSEC-2024-0414.html)

> gtk-rs GTK3 bindings - no longer maintained

| Details             |                                                |
| ------------------- | ---------------------------------------------- |
| Status              | unmaintained                |
| Package             | `gdkx11-sys`                      |
| Version             | `0.15.1`                   |
| URL                 | [https://github.com/gtk-rs/gtk3-rs/commit/508a69b63a3c5bf73790e0e59101a955847f30d6](https://github.com/gtk-rs/gtk3-rs/commit/508a69b63a3c5bf73790e0e59101a955847f30d6) |
| Date                | 2024-03-04                         |

The gtk-rs GTK3 bindings are no longer maintained.

The maintainers have archived the repository, and added a note to the crate
description and its README.md that the crates are no longer maintained.

Please take a look at [gtk4-rs](https://github.com/gtk-rs/gtk4-rs) instead.

RUSTSEC-2024-0415

gtk-rs GTK3 bindings - no longer maintained

The gtk-rs GTK3 bindings are no longer maintained.

The maintainers have archived the repository, and added a note to the crate
description and its README.md that the crates are no longer maintained.

Please take a look at gtk4-rs instead.

### [RUSTSEC-2024-0420](https://rustsec.org/advisories/RUSTSEC-2024-0420.html)

> gtk-rs GTK3 bindings - no longer maintained

| Details             |                                                |
| ------------------- | ---------------------------------------------- |
| Status              | unmaintained                |
| Package             | `gtk-sys`                      |
| Version             | `0.15.3`                   |
| URL                 | [https://github.com/gtk-rs/gtk3-rs/commit/508a69b63a3c5bf73790e0e59101a955847f30d6](https://github.com/gtk-rs/gtk3-rs/commit/508a69b63a3c5bf73790e0e59101a955847f30d6) |
| Date                | 2024-03-04                         |

The gtk-rs GTK3 bindings are no longer maintained.

The maintainers have archived the repository, and added a note to the crate
description and its README.md that the crates are no longer maintained.

Please take a look at [gtk4-rs](https://github.com/gtk-rs/gtk4-rs) instead.

RUSTSEC-2024-0419

gtk-rs GTK3 bindings - no longer maintained

The gtk-rs GTK3 bindings are no longer maintained.

The maintainers have archived the repository, and added a note to the crate
description and its README.md that the crates are no longer maintained.

Please take a look at gtk4-rs instead.

### [RUSTSEC-2024-0384](https://rustsec.org/advisories/RUSTSEC-2024-0384.html)

> `instant` is unmaintained

| Details             |                                                |
| ------------------- | ---------------------------------------------- |
| Status              | unmaintained                |
| Package             | `instant`                      |
| Version             | `0.1.12`                   |
| Date                | 2024-09-01                         |

This crate is no longer maintained, and the author recommends using the maintained [`web-time`] crate instead.

[`web-time`]: https://crates.io/crates/web-time
### [RUSTSEC-2024-0370](https://rustsec.org/advisories/RUSTSEC-2024-0370.html)

> proc-macro-error is unmaintained

| Details             |                                                |
| ------------------- | ---------------------------------------------- |
| Status              | unmaintained                |
| Package             | `proc-macro-error`                      |
| Version             | `1.0.4`                   |
| URL                 | [https://gitlab.com/CreepySkeleton/proc-macro-error/-/issues/20](https://gitlab.com/CreepySkeleton/proc-macro-error/-/issues/20) |
| Date                | 2024-09-01                         |

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](https://crates.io/crates/manyhow)
- [proc-macro-error2](https://crates.io/crates/proc-macro-error2)
- [proc-macro2-diagnostics](https://github.com/SergioBenitez/proc-macro2-diagnostics)
### [RUSTSEC-2023-0081](https://rustsec.org/advisories/RUSTSEC-2023-0081.html)

> safemem is unmaintained

| Details             |                                                |
| ------------------- | ---------------------------------------------- |
| Status              | unmaintained                |
| Package             | `safemem`                      |
| Version             | `0.3.3`                   |
| URL                 | [https://github.com/abonander/safemem](https://github.com/abonander/safemem) |
| Date                | 2023-02-14                         |

The latest crates.io release was in 2019. The repository has been archived by the author.

## Migration

- `safemem::copy_over(slice, src_idx, dest_idx, len);` can be replaced with `slice.copy_within(src_idx..src_idx+len, dest_idx);` as of `rust 1.37.0`.
- `safemem::write_bytes(slice, byte);` can be replaced with `slice.fill(byte);` as of `rust 1.50.0`
- `safemem::prepend(slice, vec);` can be replaced with

  ```rust
  let old_len = vec.len();
  vec.extend_from_slice(slice);
  vec.rotate_left(old_len);

as of rust 1.26.0

RUSTSEC-2021-0145

Potential unaligned read

On windows, atty dereferences a potentially unaligned pointer.

In practice however, the pointer won't be unaligned unless a custom global allocator is used.

In particular, the System allocator on windows uses HeapAlloc, which guarantees a large enough alignment.

atty is Unmaintained

A Pull Request with a fix has been provided over a year ago but the maintainer seems to be unreachable.

Last release of atty was almost 3 years ago.

Possible Alternative(s)

The below list has not been vetted in any way and may or may not contain alternatives;

• std::io::IsTerminal - Stable since Rust 1.70.0
• is-terminal - Standalone crate supporting Rust older than 1.70.0

RUSTSEC-2024-0429

Unsoundness in Iterator and DoubleEndedIterator impls for glib::VariantStrIter

The VariantStrIter::impl_get function (called internally by implementations of the Iterator and DoubleEndedIterator traits for this type) was unsound, resulting in undefined behaviour.

An immutable reference &p to a *mut libc::c_char pointer initialized to NULL was passed as an argument to a C function that that mutates the pointer behind &p in-place (i.e. as an out-argument), which was unsound. After changes in recent versions of the Rust compiler, these unsound writes through &p now seem to be completely disregarded when building the glib crate with optimizations.

This subsequently caused all calls of VariantStrIter::impl_get to violate the safety requirements of the std::ffi::CStr::from_ptr function - which requires its argument to be a valid pointer to a C-style string - resulting in crashes due to NULL pointer dereferences.

This was fixed by passing the out-argument pointer explitly as &mut p instead of &p.

This issue has been present since this code was initially added in glib v0.15.0. The mismatch in mutability was likely missed (and not raised as an error by the compiler) because the C function wrapped by VariantStrIter::impl_get is variadic (glib_sys::g_variant_get_child), and the pointer in question is one of the variadic arguments.

RUSTSEC-2025-0023

Broadcast channel calls clone in parallel, but does not require Sync

The broadcast channel internally calls clone on the stored value when
receiving it, and only requires T:Send. This means that using the broadcast
channel with values that are Send but not Sync can trigger unsoundness if
the clone implementation makes use of the value being !Sync.

Thank you to Austin Bonander for finding and reporting this issue.

Crate bytemuck is yanked

No extra details provided.

Crate bytes is yanked

No extra details provided.

Crate cargo_toml is yanked

No extra details provided.

Crate futures-util is yanked

No extra details provided.

Crate pest is yanked

No extra details provided.

Crate pest_derive is yanked

No extra details provided.

Crate pest_generator is yanked

No extra details provided.

Crate pest_meta is yanked

No extra details provided.