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

multi: parse own-DB blocks leniently in getblock and indexer init

Public commit record

What the developer wrote

Authored by Olaoluwa Osuntokun

83/100 · Strong
multi: parse own-DB blocks leniently in getblock and indexer init

In this commit, we extend the lenient database block parser to the remaining call sites that re-read blocks from the node's own database.

The getblock RPC now copies FetchBlock bytes before its read transaction ends, since database buffers are not valid outside that lifetime. We then strip any legacy trailing data and serve the exact block serialization at every verbosity level. A regression database invalidates its buffer as View returns, pinning the required copy.

The index manager uses the same parser while rolling an index tip back to the main chain. We also place DBBlockFromBytes before its first caller and log legacy trailing data at debug level, since a frequently fetched dirty block should not flood operator logs.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit fixes two related bugs in btcd, a Bitcoin node implementation. First, it prevents the getblock RPC from using database memory after it has expired, which could previously cause crashes or corrupted block data. Second, it makes block reading from the node's own database more forgiving of old trailing garbage bytes, so historical blocks written by older btcd versions remain readable. The change is defensive maintenance rather than an active exploit fix, and it includes new tests to verify the behavior.

Recommended action

Review and merge if not already deployed. Operators running btcd with legacy databases should upgrade to ensure getblock and indexer initialization remain reliable. No immediate emergency response is indicated, but the use-after-free-like pattern in getblock is worth backporting to stable branches.

Security signals we found

01

Use of transaction-scoped database buffer after view lifetime (getblock RPC)

02

Lenient parsing of own-DB blocks to avoid permanent unreadability of legacy data

03

Addition of regression test for buffer invalidation after DB.View

04

Strict parsing still enforced for external sources (p2p, RPC) per code comment

Risk score

Why this scored 31/100

Our methodology →
Potential impact 8/30
Exploitability 3/25
Stealth signal 4/15
Affected reach 5/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.