decode: bound the memory repeated elements and map entries materialize

[iainmcgin]

Bounds the memory a decode materializes in the elements of length-delimited containers. Closes #301.

DecodeOptions::with_element_memory_limit(bytes), defaulting to 32 MiB (DEFAULT_ELEMENT_MEMORY_LIMIT), charging each element's footprint against one budget shared by the whole decode tree. New DecodeError::ElementMemoryLimitExceeded.

The vector, measured

Nothing bounded what a repeated length-delimited field decodes into. Numbers taken against lazyviews::Payload, not estimated:

container	element	wire	materialized	ratio
repeated message	empty Payload	2 B	256 B	128x
repeated bytes	empty	2 B	32 B	16x
repeated string	empty	2 B	24 B	12x
map<string, Message>	empty value	~9 B	336 B	~37x
packed int32	1-byte varint	1 B	4 B	4x

The issue's example reproduces exactly: 4 MiB of empty repeated-message elements = 2,097,152 elements = ~512 MiB, all of it inside any input limit a caller could set. with_max_message_size cannot help — it bounds the bytes going in, not what they expand into, and the two are not proportional.

Design

Three decisions, all deliberate:

Charge bytes, not element count. A count means different amounts of memory per message: 100K elements is 25.6 MiB of Payload but 3.2 MiB of a 32-byte message. Charging size_of::<Element>() gives one uniform ceiling, which is the thing actually worth bounding.

One budget for the whole decode tree, not per field. Per field bounds nothing in aggregate — a message with fifty repeated fields gets fifty times the ceiling, and nesting multiplies further. There is a test pinning that a nested message's elements draw from its parent's pool.

Packed scalars are never charged. Their worst case is a 1-byte varint becoming a 4-byte i32. Charging them would reject the columnar payloads that carry millions of elements by design — ColumnBatch (#318) has 1024 per column, and real Arrow batches run 64K+. Lazy views are likewise uncharged: they borrow byte slices at decode and materialize on access.

The default

32 MiB is a judgement, not a derivation, and it is anchored rather than invented: DEFAULT_UNKNOWN_FIELD_LIMIT (1M x 40 B) already permits ~38 MiB, so buffa has made this call once already in the same units. This can reject input that previously decoded — raise the budget for trusted input that legitimately decodes into more.

Backward compatibility

DecodeContext::new is public and called by generated code, so changing its signature would break every consumer with checked-in generated code until they regenerate. The budget is therefore Option<&Cell<usize>>: new leaves it absent and charges nothing, so un-regenerated code behaves exactly as before; buffa's own entry points and codegen attach it. A test pins that a context built the old way is unaffected.

What review caught

The first commit had a hole big enough to make the guard theatre: maps were not charged at all. Confirmed empirically — 20,000 map<string, Address> entries materialized ~2 MB under a 1 KB budget and decoded fine. google.protobuf.Struct.fields is a map<string, Value>, so it reached a WKT. Two further public entries were unbounded: the reflective DynamicMessage decoder (which builds its own context — and is an entry point for untrusted bytes via Any unpacking and gRPC reflection) and Message::decode_length_delimited, whose own doc calls it a top-level entry point.

Worth stating plainly: the first commit passed 48 test suites and 14/14 conformance. That was not evidence it worked — every bypassed path was green because it had no test. f545423 closes the holes and adds the tests that would have caught them (maps, views, nesting). The map test fails against the first commit.

Verification

• The DecodeOptions: add a decoded-element budget for repeated fields (wire-to-owned memory amplification) #301 attack: 4 MiB / 2,097,152 elements now rejects with the typed error; a legitimate 10-element message decodes; a raised budget admits all 2M.
• 48 workspace suites, 14/14 conformance (including via-reflect, which now runs through the bounded DynamicMessage).
• RED-checked: neutering the guard fails the three rejection tests; reverting the map charge fails the map test. The tests asserting admission pass either way, correctly.
• cargo fmt --check, clippy --workspace --all-targets --all-features -D warnings, RUSTDOCFLAGS='-D warnings' cargo doc all clean.

Known scope

Vec grows by doubling, so peak resident memory can reach roughly twice the budget — this bounds what is materialized, not what the allocator reserves. Documented on the const.

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}