AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Moderate 59 Bitcoin

consensus_encoding: implement batched allocation for WitnessDecoder

Public commit record

What the developer wrote

Authored by jrakibi

91/100 · Strong
consensus_encoding: implement batched allocation for WitnessDecoder

Add batched allocation for witness decoder (data area).
we allocate incrementally in ~1 MB batches

The current approach automatically addresses the concerns raised in
https://github.com/rust-bitcoin/rust-bitcoin/issues/5258 and
https://github.com/rust-bitcoin/rust-bitcoin/pull/5239#discussion_r2501954586

we aslo add `reserve_batch` to Mutants exclusion list
Mutation testing in WitnessDecoder::reserve_batch changes the buffer
allocation logic and they cause infinite loop during decoding
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit changes how the Rust Bitcoin library allocates memory when decoding a Bitcoin transaction's witness data. Previously, the decoder could double its internal buffer repeatedly, which could let a maliciously crafted transaction force the program to reserve far more memory than needed. The new code allocates memory in roughly 1 MB batches instead. A test was added that feeds a 4,000,000-element witness and checks that the decoder only allocates about 16–17.5 MB, suggesting the change is meant to limit memory blow-up during decoding.

Recommended action

Review whether the 1 MB batch size and the 16–17.5 MB test bound are appropriate DoS limits for all deployment contexts. Verify that reserve_batch cannot be driven into an infinite loop when required_len is very large and that partial reads correctly resume after each batch. Consider fuzzing push_bytes with malformed CompactSize lengths and large witness counts.

Security signals we found

01

Memory-allocation behavior change in a network-facing decoder

02

New constant MAX_VECTOR_ALLOCATE = 1_000_000 limits single allocation size

03

Replacement of exponential buffer growth with batched linear growth

04

Added test named test_dos_protection with adversarial witness count/length

05

References to GitHub issue #5258 and PR review about allocation concerns

Risk score

Why this scored 59/100

Our methodology →
Potential impact 18/30
Exploitability 12/25
Stealth signal 8/15
Affected reach 10/15
Confidence 7/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.