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.

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.