[zshenker]

Problem

Token::from_bytes decodes untrusted input, but its recursive CBOR map/array decoder trusted two things from that input:

• Allocation from a declared length. decode_array pre-allocated Vec::with_capacity(declared_len) straight from the array header, so a declared length near 2^64 panicked ("capacity overflow") before any element was read.
• Unbounded recursion. Decoding recursed once per nesting level with no bound, so deeply nested arrays or maps overflowed the stack and aborted the process.

Indefinite-length arrays and maps were also read as empty, which misparsed whatever followed.

Change

• A declared array or map length that the remaining input can't hold is rejected before allocating or iterating. Each item needs at least one byte, and each map entry two.
• Container nesting is capped at 32 levels (MAX_NESTING_DEPTH). CWT, COSE and CAT structures nest only a few.
• Indefinite-length arrays and maps are rejected explicitly.
• All three return Error::InvalidFormat. The limits apply to the protected header, unprotected header and payload, and to every nested claim value. Valid tokens are unaffected, and the public API is unchanged.
• A cargo-fuzz target (fuzz/) exercises Token::from_bytes, to_bytes and verify_claims on arbitrary input. It is excluded from the published crate.

Tests

• Seven regression tests run each case in each position (protected header, unprotected header, payload): a 2^64-1 array, an oversized map, nesting 200,000 deep, the depth boundary (31 levels pass, 32 fail), indefinite-length containers, oversized strings, and a nested catu claim that must still decode.
• cargo clippy --all-targets -- -D warnings and cargo test pass, with 62 unit tests and 73 doctests.
• A 60-second fuzz run of about 2M inputs found no crashes.

🤖 Generated with Claude Code

[thomshutt-fastly]

I think that assigning capacity like this can end up eating quite a bit of memory in the worst MAX_NESTING_DEPTH nested array case - is it worth considering Vec::new() instead?