[ara-stock]

Problem

The borsh and wincode deserializers generated by prefixed_vec_type! (collections/src/vec.rs) call Vec::with_capacity(prefix) with the length prefix read from the input, before any item is read. A short input with a large prefix therefore panics or aborts instead of returning an error:

• U64PrefixedVec::<u8>::try_from_slice(&u64::MAX.to_le_bytes()) (8 bytes) panics with capacity overflow, and so does wincode::deserialize::<U64PrefixedVec<u8>> on the same bytes;
• U32PrefixedVec::<u64>::try_from_slice(&u32::MAX.to_le_bytes()) (4 bytes) tries to allocate ~32 GiB and aborts the process (memory allocation of 34359738360 bytes failed);
• on-chain, with a 32 KiB heap, a much smaller prefix is enough to abort.

The U*PrefixedStr types are built on these, so they're affected too. borsh's own Vec<T> impl avoids this by capping the initial capacity at 4096 bytes (borsh::de::hint::cautious), and wincode applies its preallocation limit, but these custom impls skip both.

Summary of Changes

• Add a small cautious_capacity::<T>(prefix) helper that caps the initial capacity at 4096 bytes worth of items (same as borsh), and use it in both the borsh and wincode PrefixedVec deserializers. The read loop and wire format are unchanged; vectors over that size just grow as items are read.
• Add prefixed_vec_borsh_with_oversized_prefix and prefixed_vec_wincode_with_oversized_prefix. Both panic on main and pass with this change.

cargo test --all-features for spl-collections, cargo fmt --check, clippy with the Makefile's deny flags, and cargo check with no features / borsh only / wincode only are all clean.

I used an AI assistant (Claude) while preparing this. I reproduced the issue and checked the fix and tests myself.

🤖 Generated with Claude Code

[joncinque]

Thanks for your contribution. If we want to limit this to any number, we should probably go with the maximum heap size allowed on-chain: https://github.com/anza-xyz/solana-sdk/blob/47e7cfc9c7563879eb32a5efac9b6f6243923407/message/src/versions/v1/mod.rs#L38

Or we can use the default.

What do you think @febo ?

[ara-stock]

Thanks! Note this only caps the initial with_capacity; the Vec still grows as items are actually read, so any prefix that is backed by real data still deserializes. 4096 bytes mirrors borsh's own cautious hint for Vec<T>. Using the max heap size from the link instead works too (it bounds the allocation to what can exist on-chain while avoiding reallocations for large vectors); happy to switch the constant to that, or to drop the custom cap and rely on the default, whichever you and @febo prefer.