Repository navigation
Unbounded allocation in VecOf decode #567
Description
The VecOf<T> SCALE decoder in dstack/ra-tls/src/attestation/mod.rs reads a length prefix from untrusted input and pre-allocates a Vec of that size without any upper bound, enabling an attacker to trigger arbitrarily large memory allocations with a crafted payload.
Root Cause
The VecOf decoder reads a count value from untrusted input and allocates a vector of that size without any upper bound:
// codecs.rs:24-37
let count = u32::decode(input)?;
let mut items = Vec::with_capacity(count as usize); // Unbounded allocation
for _ in 0..count {
items.push(T::decode(input)?);
}A malformed event log entry with a large count value can trigger allocation of gigabytes of memory.
Attack Path
- Attacker crafts a malformed CCEL (CC Event Log) entry with
count = 0xFFFFFFFF - Application parses the event log using the
VecOfdecoder Vec::with_capacity(4294967295)attempts to allocate ~4 GB- Process crashes due to OOM or the system becomes unresponsive
Impact
Denial of service when parsing malformed event logs. The event log could be corrupted by a malicious host (the CCEL table is provided by the firmware/VMM) or by a compromised process inside the CVM.
Suggested Fix
Add a maximum count limit:
const MAX_VEC_COUNT: u32 = 65536; // Reasonable upper bound
let count = u32::decode(input)?;
if count > MAX_VEC_COUNT {
return Err(Error::CountTooLarge(count));
}
let mut items = Vec::with_capacity(count as usize);Note: This issue was created automatically. The vulnerability report was generated by Claude and has not been verified by a human.
Activity
kvinwang commentedon Mar 18, 2026
Fixed in #570. Added a const generic
MAX_LENwith a default of 65536 toVecOf, so decode now rejects counts exceeding the limit. Also cappedwith_capacityto 1024 to prevent large pre-allocations from untrusted input.Existing
VecOf<I, T>usages are unaffected due to the default value. Callers can override with e.g.VecOf<u32, u8, 1048576>if needed.h4x3rotab commentedon Jun 30, 2026
Maintainer triage update: this was fixed by #570 and is recorded in the public security report table: https://github.com/Dstack-TEE/dstack/blob/master/docs/security/public-security-reports.md#public-reports-and-findings
Disposition: valid report, fixed. #570 caps
VecOfdecode length and pre-allocation.Closing as fixed.