fix: guard NiPoPow scorex_parse against allocation bomb - #855
Conversation
…d input A crafted P2P payload could set num_prefixes/num_suffix_tail to 0x7FFFFFFF, causing Vec::with_capacity to request ~790 GB and SIGABRT the node. Add sanity caps to all five attacker-controlled size fields in NipopowProof::scorex_parse and PoPowHeader::scorex_parse. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
c34fd06 to
355e769
Compare
|
I prepared the parser-framing follow-up on top of the current v0.30.0 base while leaving this PR as the owning contribution. Branch and diff: v0.30.0...bounded framing The branch contains the allocation guards from #855 on the current base, followed by:
The outer element helper reads exactly the declared number of bytes from the stream but deliberately does not require the parsed element to consume the whole slice, matching the JVM parseBytes behavior for padding inside a frame. Allocation caps remain checked before buffer creation. Validation on the combined branch:
No competing PR was opened. After rebasing #855 onto the current v0.30.0 head, the two follow-up commits can be cherry-picked directly. |
Summary
num_prefixesor other size fields to0x7FFFFFFF, causingVec::with_capacityto request ~790 GB and SIGABRT the nodeNipopowProof::scorex_parseandPoPowHeader::scorex_parseErrinstead of crashingGuarded fields
NipopowProof::scorex_parsenum_prefixesNipopowProof::scorex_parsenum_suffix_tailPoPowHeader::scorex_parseheader_sizePoPowHeader::scorex_parseinterlinks_sizePoPowHeader::scorex_parseproof_bytesTest plan
crafted_huge_prefix_count_returns_err—num_prefixes = 0x7FFFFFFF→Errcrafted_huge_header_size_returns_err—header_size = 0x7FFFFFFF→Errcrafted_header_size_just_over_limit_returns_err—header_size = 10,001→Errnipopowproof_roundtripproptest still passes🤖 Generated with Claude Code