RUSTSEC-2026-0432: `codeq`: decoding untrusted input can allocate memory from an unchecked length prefix (denial of service)

Published Oct 31, 2026
·
Updated

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

1 affected componentFixes available
rust/codeq>=0.0.0-0<0.6.3
0.6.3

Event History

Oct 31, 2026
Advisory Published
via OSV·12:00 PM
Data Sourced
via OSV·12:00 PM
DescriptionSeverityAffected Software

Frequently Asked Questions

1

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.

2

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.

3

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.

4

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.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203