This project might be open to known security vulnerabilities, which can be prevented by tightening the version range of affected dependencies. Find detailed information at the bottom.

Crate webrtc-util

Dependencies

(12 total, 4 outdated, 1 possibly insecure)

CrateRequiredLatestStatus
 async-trait^0.10.1.89up to date
 bitflags^1.32.11.0out of date
 bytes ⚠️^11.11.1maybe insecure
 ipnet^2.6.02.12.0up to date
 lazy_static^11.5.0up to date
 libc^0.2.1260.2.183up to date
 log^0.40.4.29up to date
 nix^0.26.20.31.2out of date
 rand^0.80.10.0out of date
 thiserror^12.0.18out of date
 tokio^1.32.01.50.0up to date
 winapi^0.3.90.3.9up to date

Dev dependencies

(5 total, 3 outdated)

CrateRequiredLatestStatus
 async-global-executor^23.1.0out of date
 chrono^0.4.280.4.44up to date
 criterion^0.50.8.2out of date
 env_logger^0.100.11.10out of date
 tokio-test^0.40.4.5up to date

Security Vulnerabilities

bytes: Integer overflow in `BytesMut::reserve`

RUSTSEC-2026-0007

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.