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

rpc: replace get_blocks.bin Levin pool budget

Public commit record

What the developer wrote

Authored by selsta

68/100 · Adequate
rpc: replace get_blocks.bin Levin pool budget

/get_blocks.bin is HTTP binary RPC serialized with portable storage, not a
P2P Levin message. The previously added pool limiter used
LEVIN_DEFAULT_MAX_PACKET_SIZE as a response budget, but that constant does
not apply to the RPC path.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This Monero code change fixes how the /get_blocks.bin RPC endpoint limits the size of transaction-pool data it returns. Previously, the code reused a P2P Levin packet-size constant that does not apply to HTTP RPC responses, and it tried to budget pool data against the size of the block data already sent. The patch removes that size-budget plumbing and instead caps the number of added pool transactions at a fixed maximum (20,000). This is a correctness fix for response-size limiting, but it also removes a cumulative byte-size cap that could, in edge cases, allow very large individual transactions to make responses bigger than intended.

Recommended action

Treat this as a hardening/correctness patch rather than a confirmed vulnerability. Operators should upgrade to avoid RPC response-size anomalies. Reviewers should verify that the new 20,000 transaction count cap, combined with existing HTTP server limits, provides adequate DoS protection for the /get_blocks.bin endpoint, especially against large or maliciously crafted transactions.

Security signals we found

01

Incorrect transport-layer size constant reused for HTTP RPC response limiting

02

Removal of cumulative byte-size cap on returned transaction pool blobs

03

Replacement with a count-based cap (20,000 transactions)

04

Potential for oversized RPC responses if individual transactions are very large

05

Fixes a logic bug where block-data size could zero out pool-info budget

Risk score

Why this scored 49/100

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