RUSTSEC-2026-0432: `codeq`: decoding untrusted input can allocate memory from an unchecked length prefix (denial of service)
codeq is a serialization library whose Decode trait reads length-prefixed values. For String and Vec<u8>, the length-prefixed Decode implementations read a 4-byte big-endian length and allocate a buffer of that size before reading the payload. Because the declared length is taken straight from the input with no upper bound and no cross-check against the bytes actually available, a tiny input can force an allocation of up to ~4 GiB. Code that decodes untrusted data through codeq can therefore be made to spike memory use and be OOM-killed (CWE-400, uncontrolled resource consumption).
The affected path, in src/codec/impls/stringimpl.rs:
rust impl Decode for String { fn decode<R: io::Read>(mut r: R) -> Result<Self, io::Error> { let len = r.readu32::<BigEndian>()? as usize; let mut buf = vec![0; len]; // allocates len bytes up front r.readexact(&mut buf)?; String::fromutf8(buf).maperr(|e| io::Error::new(io::ErrorKind::InvalidData, e)) } }
Any code that decodes attacker-controlled bytes through codeq can be forcedcto allocate up to ~4 GiB per decode call from a 4-byte length prefix. On a service decoding untrusted input this is a cheap denial of service (crash / OOM-kill). The practical severity depends on how the embedding wires codeq to untrusted bytes.
Remediation
Fixed in 0.6.3, which grows the decode buffers as payload bytes actually arrive instead of pre-allocating the full declared length (commit 9f15313, "fix: codec: grow decode buffers as payload bytes arrive"). Upgrade to codeq >= 0.6.3.
Affected Software
Event History
Frequently Asked Questions
Who is exposed to this denial-of-service issue?
Applications that decode attacker-controlled or otherwise untrusted bytes through codeq are exposed. The affected decoding path applies to String and Vec<u8> length-prefixed values.
What does an attacker need to trigger the issue?
An attacker only needs to supply input containing a chosen 4-byte big-endian length prefix to a reachable codeq Decode call. The declared payload does not need to be present, because allocation occurs before the payload is read.
Are default length limits or available-input checks applied before allocation?
No. The decoded length is taken directly from input without an upper bound or a check that the stated number of bytes is available before allocating the buffer.
How large can the forced allocation be?
A single decode call can be made to allocate up to approximately 4 GiB based on the 4-byte length prefix. Repeated requests or concurrent decoding can increase memory pressure and may cause the process to be OOM-killed.