In the unique reclaim path of BytesMut::reserve, the condition

if v_capacity >= new_cap + offset

uses an unchecked addition. When new_cap + offset overflows usize in release builds, this condition may incorrectly pass, causing self.cap to be set to a value that exceeds the actual allocated capacity. Subsequent APIs such as spare_capacity_mut() then trust this corrupted cap value and may create out-of-bounds slices, leading to UB.

This behavior is observable in release builds (integer overflow wraps), whereas debug builds panic due to overflow checks.

PoC

use bytes::*;

fn main() {
    let mut a = BytesMut::from(&b"hello world"[..]);
    let mut b = a.split_off(5);

    // Ensure b becomes the unique owner of the backing storage
    drop(a);

    // Trigger overflow in new_cap + offset inside reserve
    b.reserve(usize::MAX - 6);

    // This call relies on the corrupted cap and may cause UB & HBO
    b.put_u8(b'h');
}

Workarounds

Users of BytesMut::reserve are only affected if integer overflow checks are configured to wrap. When integer overflow is configured to panic, this issue does not apply.

Diesel allows users to configure various options for PostgreSQL's COPY FROM and COPY TO statements. These configurations are partially provided as strings or characters.

Diesel did not check if any these user-provided options contain a quote character ', which can lead to the injection of additional options in the current COPY FROM/COPY TO statement.

This vulnerability affects any user of COPY FROM/COPY TO that passes user-provided input to any of the affected functions. It can result in modifications of options in the current statement, but it is not possible inject additional statements.

Mitigation

The preferred mitigation to the outlined problem is to update to Diesel version 2.3.8 or newer, which includes fixes for the problem.

Resolution

Diesel now correctly escapes any quotes contained in the provided arguments.

Diesel allows to register custom aggregate SQL functions for SQLite via the SqliteAggregate interface.

To store an instance of the custom aggregate processor Diesel relied on the sqlite3_aggregate_context function provided by sqlite. This function doesn't provide any guarantees about alignment of the returned allocation, which in turn can lead to problems if the type implementing requires a special alignment, e.g. via a custom #[align(x)] attribute on the type implementing this trait. This affects any user of SqliteAggregate that registers the custom aggregate function with an SQLite connection, while using a non-standard alignment on the type implementing this trait.

Mitigation

The preferred mitigation to the outlined problem is to update to a Diesel version 2.3.8 or newer, which includes fixes for the problem.

Resolution

Diesel now allocates the corresponding memory on Rust side to get a correctly aligned allocation.

Uint::overflowing_shl/overflowing_shr returned false-negative overflow flags. overflowing_shl missed bits shifted above BITS but within the top limb (non-limb-aligned widths such as U160), and limbs wholly discarded by shifts >= 64; overflowing_shr missed wholly discarded low limbs. Shifted values were correct; only the flag was wrong.

The wrong flag propagates: checked_shl/checked_shr return Some instead of None, strict_* fail to panic, and saturating_* return a wrapped value instead of saturating. The incorrect checked_shl result causes to_base_be (and string formatting) to loop forever on no-alloc builds for non-limb-aligned widths — a denial of service if formatting is reachable from untrusted input.

Separately, wrapping_shl/wrapping_shr on 64/128/256-bit types truncated the shift amount modulo 2^32, so shifts >= 2^32 returned an incorrectly wrapped value instead of zero; on 32-bit targets the generic path also truncated 64-bit shift amounts.

Callers using checked or saturating shift semantics on untrusted shift amounts may compute incorrect results.

Insufficient archive range validation could allow a crafted archive to reach ArchivedString::deserialize with an invalid pointer. A reported reproducer used rkyv::from_bytes to deserialize a struct containing strings, a vector, a box, and an optional hash map. AddressSanitizer detected a heap use-after-free during string deserialization.

The flaw could be triggered through the safe checked deserialization API when processing malicious archive bytes. Version 0.8.17 rejects the malformed archive during validation. Users who process untrusted archives should upgrade to 0.8.17 or later.

The archive validator could accept certain malformed relative pointers and invalid ArchivedHashTable states. In particular, the hash table verifier did not ensure that the number of occupied buckets matched the table's declared length.

A crafted archive could pass the checks performed by the safe rkyv::access and rkyv::from_bytes APIs and then cause an out-of-bounds read in later validation, lookup, or deserialization. Depending on the input, this could perform scalar or SIMD reads outside the archive buffer or crash the process.

Version 0.8.17 strengthens archive range validation and rejects hash tables whose number of occupied buckets does not match their declared length. Users who process untrusted archives should upgrade to 0.8.17 or later.

Shared pointer validation keyed already-validated pointees by their address and type, but did not include pointer metadata. For unsized pointees, an archive could therefore contain multiple Rc, Arc, or weak pointers that shared a data address but used different metadata, such as different slice lengths.

Once the first pointer had been validated, later pointers to the same address skipped pointee validation. The safe checked rkyv::access API could consequently return a slice with a forged length, allowing safe indexing to read out of bounds. The same validation bypass was reachable through checked deserialization with rkyv::from_bytes.

Version 0.8.17 includes pointer metadata in shared pointer validation and rejects conflicting metadata. The 0.7 series is also affected but is no longer supported by upstream. Users who process untrusted archives should upgrade to 0.8.17 or later.