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

psbt: avoid blocking reads and unbounded allocations in NewFromRawBytes

Public commit record

What the developer wrote

Authored by Olaoluwa Osuntokun

73/100 · Adequate
psbt: avoid blocking reads and unbounded allocations in NewFromRawBytes

In this commit, we address two issues with the strict parsing recently
added to NewFromRawBytes.

First, the trailing data check probed the caller supplied reader with a
blocking one byte read. A reader without a Len method (net.Conn,
io.Pipe) that stays open after delivering a complete packet would hang
the parser forever. We now only enforce the check when the reader can
report its remaining length without an additional read, which covers
in-memory readers along with the decoded base64 path. Plain streams are
left positioned directly after the packet, and the reader contract is
now documented on NewFromRawBytes.

Second, the base64 path read the entire input into memory before any
validation ran, so a very large input could force an arbitrarily large
allocation before the first validity check. We now bound the read to
wire.MaxMessagePayload expanded by the base64 encoding overhead.

Along the way, we simplify assertFullyConsumed down to the bytes.Reader
case that all remaining callers use.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit fixes two problems in the way btcd reads Partially Signed Bitcoin Transactions (PSBTs). First, the parser could hang forever when reading from a network connection or pipe because it tried to read one extra byte to check for leftover data. Second, when given a base64-encoded PSBT, it would read the entire input into memory before checking whether it was valid, so a maliciously huge input could force the program to allocate enormous amounts of RAM. The patch limits how much base64 data is read and only checks for trailing bytes when the reader can safely report its remaining length.

Recommended action

Treat this as a security hardening fix and include it in the next release. Users parsing PSBTs from untrusted network streams or base64 inputs should upgrade. Review other io.Reader consumers in the codebase for similar blocking trailing-data checks or unbounded io.ReadAll calls.

Security signals we found

01

Denial-of-service via blocking read on open stream (potential infinite hang)

02

Denial-of-service via unbounded memory allocation on base64 input before validation

03

Strict parsing hardening for PSBT base64 decoding

04

Reader contract documented for NewFromRawBytes

Risk score

Why this scored 64/100

Our methodology →
Potential impact 18/30
Exploitability 12/25
Stealth signal 10/15
Affected reach 12/15
Confidence 8/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.