The SharedPointer::alloc implementation for sync::Arc<T> and rc::Rc<T> in rkyv/src/impls/alloc/rc/atomic.rs (and rc.rs) does not check if the allocator returns a null pointer on OOM (Out of Memory).

This null pointer can flow through to SharedPointer::from_value, which calls Box::from_raw(ptr) with the null pointer. This triggers undefined behavior when utilizing safe deserialization APIs (such as rkyv::from_bytes or rkyv::deserialize_using) if an OOM condition occurs during the allocation of the shared pointer.

The issue is reachable through safe code and violates Rust's safety guarantees.

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.

PyO3 0.24.0 added optimized implementations of Iterator::nth and DoubleEndedIterator::nth_back for the BoundListIterator and BoundTupleIterator types. These implementations computed the target index using unchecked usize addition (index + n) before bounds-checking against the sequence length, then read the element via get_item_unchecked.

In nth methods, a sufficiently large n (combined with a non-zero internal index) could cause the addition to overflow and wrap around, producing a small "target index" that passed the bounds check and enabling reads at the front of the list or tuple of elements previously yielded by the iterator.

In nth_back methods, a sufficiently large n could cause underflow in a similar fashion, however would instead allow reads of arbitrary memory past the end of the list or tuple storage.

PyO3 0.29.0 has corrected these methods to use checked arithmetic at the positions which could be at risk of overflow.

PyCFunction::new_closure (and the temporary new_closure_bound complement in the 0.21–0.22 series) required the supplied closure to be Send + 'static but not Sync. The resulting PyCFunction is a Python callable that can be invoked from any Python thread, which means the closure may be called concurrently from multiple threads, and needs a Sync bound to prevent possible data races.

The problem exists under all Python versions but is particularly vulnerable under the newer free-threaded Python variant, which do not have serial execution imposed by the Global Interpreter Lock. Under releases protected by the GIL, the ability to "detach" from the Python interpreter temporarily inside the closure (e.g. by Python::detach) makes it possible for interleaved and/or concurrent execution of various portions of the closure.

PyO3 0.29.0 added a Sync bound to close this thread-safety bug.