fix(chain): cap block::Hash and CountedHeader preallocation at protocol-level constants (#10570)

`block::Hash::max_allocation` previously returned 65,535 (derived from
`MAX_PROTOCOL_MESSAGE_LEN / 32`), and `CountedHeader::max_allocation`
returned ~1,409 (same message-size-derived shape). Both are reachable via
`Vec::zcash_deserialize` from any post-handshake peer through `getblocks`,
`getheaders`, and `headers` messages. A peer can claim up to those counts
and force `Vec::with_capacity` preallocation before any payload bytes are
read.

Cap at protocol-level constants:
- `MAX_BLOCK_LOCATOR_LENGTH = 101`, a new `block`-module constant that
  matches Bitcoin Core's `MAX_LOCATOR_SZ` in `net_processing.cpp` (which
  zcashd inherits).
- The existing `MAX_HEADERS_PER_MESSAGE = 160` constant from
  `crate::serialization::zcash_serialize`, already enforced on the sending
  side and at the codec level for `read_headers` (PR #10528).

Same fix shape applied to `AddrV1`/`AddrV2` in PR #10494 for
GHSA-xr93-pcq3-pxf8.

CWE-770 (Allocation of Resources Without Limits or Throttling).

Tests:
- `block_hash_max_allocation` proptest updated to assert
  `Hash::max_allocation() == MAX_BLOCK_LOCATOR_LENGTH`.
- `counted_header_max_allocation` proptest updated to assert
  `CountedHeader::max_allocation() == MAX_HEADERS_PER_MESSAGE as u64`.
- Test-only constants `BLOCK_HEADER_LENGTH` and `MIN_COUNTED_HEADER_LEN`,
  which were used by the old message-size-derived formula in `header.rs`,
  moved into the `preallocate` test module where they are the only
  consumers.

Co-authored-by: dingledropper <dingledropper@users.noreply.github.com>

Author: dingledropper

CHANGELOG.md

@@ -16,6 +16,16 @@ and this project adheres to [Semantic Versioning](https://semver.org).
   the per-type `max_allocation()` caps from PR #10494
   ([GHSA-xr93-pcq3-pxf8](https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-xr93-pcq3-pxf8)).
   CWE-770.
+- Cap `block::Hash::max_allocation` at `MAX_BLOCK_LOCATOR_LENGTH = 101`
+  (matching Bitcoin Core's `MAX_LOCATOR_SZ` in `net_processing.cpp`) and
+  `CountedHeader::max_allocation` at the existing
+  `MAX_HEADERS_PER_MESSAGE = 160` constant (already enforced on the
+  sending side and at the codec level for `read_headers`). The previous
+  values were derived from `MAX_PROTOCOL_MESSAGE_LEN` and returned 65,535
+  and ~1,409 respectively, allowing a post-handshake peer to force ~2 MiB
+  of upfront `Vec` preallocation per `getblocks`/`getheaders` message
+  before any payload bytes were read. Same fix shape as
+  GHSA-xr93-pcq3-pxf8 for `AddrV1`/`AddrV2` (PR #10494). CWE-770.
 
 ### Added
 

zebra-chain/src/block.rs

@@ -11,7 +11,7 @@ use crate::{
     orchard,
     parameters::{Network, NetworkUpgrade},
     sapling,
-    serialization::{TrustedPreallocate, MAX_PROTOCOL_MESSAGE_LEN},
+    serialization::TrustedPreallocate,
     sprout,
     transaction::Transaction,
     transparent,
@@ -258,14 +258,30 @@ impl<'a> From<&'a Block> for Hash {
     }
 }
 
-/// A serialized Block hash takes 32 bytes
-const BLOCK_HASH_SIZE: u64 = 32;
+/// The maximum number of `block::Hash` entries Zebra will preallocate for in
+/// a single peer-deserialized vector.
+///
+/// In the P2P protocol, `Vec<block::Hash>` appears as the `known_blocks` block
+/// locator in `getblocks` and `getheaders` messages. The Bitcoin/Zcash
+/// convention encodes locators with exponentially-spaced heights (1, 2, 3, …,
+/// 10, 20, 40, …, genesis), giving `~log2(N) + 10` entries for chain length N.
+/// For current Zcash chain heights (~3M blocks) a legitimate locator has ~32
+/// entries.
+///
+/// We cap at 101 to match Bitcoin Core's `MAX_LOCATOR_SZ` constant
+/// (`net_processing.cpp`), which zcashd inherits. This avoids any risk of
+/// rejecting legitimate locators sent by compatible nodes that follow the
+/// existing Bitcoin/Zcash protocol convention.
+///
+/// Without this cap, `Hash::max_allocation` was previously derived from
+/// `MAX_PROTOCOL_MESSAGE_LEN / 32 = 65,535`, which allowed a remote peer to
+/// force ~2 MiB heap preallocation per crafted `getblocks`/`getheaders` message
+/// before any payload was read. This is the same class as
+/// GHSA-xr93-pcq3-pxf8 (`addr_limit`), fixed for AddrV1/V2 in PR #10494.
+pub const MAX_BLOCK_LOCATOR_LENGTH: u64 = 101;
 
-/// The maximum number of hashes in a valid Zcash protocol message.
 impl TrustedPreallocate for Hash {
     fn max_allocation() -> u64 {
-        // Every vector type requires a length field of at least one byte for de/serialization.
-        // Since a block::Hash takes 32 bytes, we can never receive more than (MAX_PROTOCOL_MESSAGE_LEN - 1) / 32 hashes in a single message
-        ((MAX_PROTOCOL_MESSAGE_LEN - 1) as u64) / BLOCK_HASH_SIZE
+        MAX_BLOCK_LOCATOR_LENGTH
     }
 }

zebra-chain/src/block/header.rs

@@ -8,7 +8,7 @@ use thiserror::Error;
 use crate::{
     fmt::HexDebug,
     parameters::Network,
-    serialization::{TrustedPreallocate, MAX_PROTOCOL_MESSAGE_LEN},
+    serialization::{TrustedPreallocate, MAX_HEADERS_PER_MESSAGE},
     work::{difficulty::CompactDifficulty, equihash::Solution},
 };
 
@@ -152,27 +152,21 @@ pub struct CountedHeader {
     pub header: Arc<Header>,
 }
 
-/// The serialized size of a Zcash block header.
-///
-/// Includes the equihash input, 32-byte nonce, 3-byte equihash length field, and equihash solution.
-const BLOCK_HEADER_LENGTH: usize =
-    crate::work::equihash::Solution::INPUT_LENGTH + 32 + 3 + crate::work::equihash::SOLUTION_SIZE;
-
-/// The minimum size for a serialized CountedHeader.
-///
-/// A CountedHeader has BLOCK_HEADER_LENGTH bytes + 1 or more bytes for the transaction count
-pub(crate) const MIN_COUNTED_HEADER_LEN: usize = BLOCK_HEADER_LENGTH + 1;
-
 /// The Zcash accepted block version.
 ///
 /// The consensus rules do not force the block version to be this value but just equal or greater than it.
 /// However, it is suggested that submitted block versions to be of this exact value.
 pub const ZCASH_BLOCK_VERSION: u32 = 4;
 
 impl TrustedPreallocate for CountedHeader {
+    /// Cap `CountedHeader` preallocation at the existing protocol-level
+    /// constant `MAX_HEADERS_PER_MESSAGE = 160`. The previous return value was
+    /// derived from `MAX_PROTOCOL_MESSAGE_LEN`, allowing peer-controlled
+    /// preallocation amplification — same shape as GHSA-xr93-pcq3-pxf8 for
+    /// `AddrV1`/`AddrV2` (PR #10494).
     fn max_allocation() -> u64 {
-        // Every vector type requires a length field of at least one byte for de/serialization.
-        // Therefore, we can never receive more than (MAX_PROTOCOL_MESSAGE_LEN - 1) / MIN_COUNTED_HEADER_LEN counted headers in a single message
-        ((MAX_PROTOCOL_MESSAGE_LEN - 1) / MIN_COUNTED_HEADER_LEN) as u64
+        // Cast safe: MAX_HEADERS_PER_MESSAGE is the constant 160, which fits
+        // trivially in u64 on every platform.
+        MAX_HEADERS_PER_MESSAGE as u64
     }
 }

zebra-chain/src/block/tests/preallocate.rs

@@ -5,41 +5,58 @@ use std::sync::Arc;
 use proptest::prelude::*;
 
 use crate::{
-    block::{
-        header::MIN_COUNTED_HEADER_LEN, CountedHeader, Hash, Header, BLOCK_HASH_SIZE,
-        MAX_PROTOCOL_MESSAGE_LEN,
+    block::{CountedHeader, Hash, Header, MAX_BLOCK_LOCATOR_LENGTH},
+    serialization::{
+        arbitrary::max_allocation_is_big_enough, TrustedPreallocate, ZcashSerialize,
+        MAX_HEADERS_PER_MESSAGE, MAX_PROTOCOL_MESSAGE_LEN,
     },
-    serialization::{arbitrary::max_allocation_is_big_enough, TrustedPreallocate, ZcashSerialize},
 };
 
+/// The serialized size of a Zcash block header.
+///
+/// Equihash input + 32-byte nonce + 3-byte equihash solution-length field +
+/// equihash solution. Used as a serialized-size lower bound by the
+/// `counted_header_min_length` proptest.
+const BLOCK_HEADER_LENGTH: usize =
+    crate::work::equihash::Solution::INPUT_LENGTH + 32 + 3 + crate::work::equihash::SOLUTION_SIZE;
+
+/// The minimum size for a serialized `CountedHeader`: header bytes plus at
+/// least one byte for the transaction count CompactSize.
+const MIN_COUNTED_HEADER_LEN: usize = BLOCK_HEADER_LENGTH + 1;
+
 proptest! {
-    /// Verify that the serialized size of a block hash used to calculate the allocation limit is correct
+    /// Verify that the serialized size of a block hash is 32 bytes, matching the protocol spec.
     #[test]
     fn block_hash_size_is_correct(hash in Hash::arbitrary()) {
         let serialized = hash.zcash_serialize_to_vec().expect("Serialization to vec must succeed");
-        prop_assert!(serialized.len() as u64 == BLOCK_HASH_SIZE);
+        prop_assert!(serialized.len() as u64 == 32);
     }
 
     /// Verify that...
-    /// 1. The smallest disallowed vector of `Hash`s is too large to send via the Zcash Wire Protocol
-    /// 2. The largest allowed vector is small enough to fit in a legal Zcash Wire Protocol message
+    /// 1. `Hash::max_allocation` is exactly `MAX_BLOCK_LOCATOR_LENGTH`. The cap is intentionally
+    ///    far smaller than the message-size limit, to prevent peer-controlled preallocation
+    ///    amplification (sibling of GHSA-xr93-pcq3-pxf8).
+    /// 2. The largest allowed vector still fits in a legal Zcash Wire Protocol message.
     #[test]
     fn block_hash_max_allocation(hash in Hash::arbitrary_with(())) {
         let (
             smallest_disallowed_vec_len,
-            smallest_disallowed_serialized_len,
+            _smallest_disallowed_serialized_len,
             largest_allowed_vec_len,
             largest_allowed_serialized_len,
         ) = max_allocation_is_big_enough(hash);
 
+        // The cap is exactly the locator-protocol cap, not derived from message size.
+        prop_assert!(Hash::max_allocation() == MAX_BLOCK_LOCATOR_LENGTH);
+
         // Check that our smallest_disallowed_vec is only one item larger than the limit
         prop_assert!(((smallest_disallowed_vec_len - 1) as u64) == Hash::max_allocation());
-        // Check that our smallest_disallowed_vec is too big to send as a protocol message
-        prop_assert!(smallest_disallowed_serialized_len > MAX_PROTOCOL_MESSAGE_LEN);
 
         // Check that our largest_allowed_vec contains the maximum number of hashes
         prop_assert!((largest_allowed_vec_len as u64) == Hash::max_allocation());
+
         // Check that our largest_allowed_vec is small enough to send as a protocol message
+        // (this is now slack: the locator cap is much smaller than the message-size limit).
         prop_assert!(largest_allowed_serialized_len <= MAX_PROTOCOL_MESSAGE_LEN);
     }
 
@@ -59,8 +76,12 @@ proptest! {
     #![proptest_config(ProptestConfig::with_cases(128))]
 
     /// Verify that...
-    /// 1. The smallest disallowed vector of `CountedHeaders`s is too large to send via the Zcash Wire Protocol
-    /// 2. The largest allowed vector is small enough to fit in a legal Zcash Wire Protocol message
+    /// 1. `CountedHeader::max_allocation` is exactly `MAX_HEADERS_PER_MESSAGE`. The cap is a
+    ///    protocol-level constant (160 headers per `headers` message — the Zcash convention
+    ///    Zebra already enforces on the sending side and at the codec level for `read_headers`)
+    ///    rather than a message-size-derived value, to prevent peer-controlled preallocation
+    ///    amplification (sibling of GHSA-xr93-pcq3-pxf8).
+    /// 2. The largest allowed vector still fits in a legal Zcash Wire Protocol message.
     #[test]
     fn counted_header_max_allocation(header in any::<Arc<Header>>()) {
         let header = CountedHeader {
@@ -69,19 +90,23 @@ proptest! {
 
         let (
             smallest_disallowed_vec_len,
-            smallest_disallowed_serialized_len,
+            _smallest_disallowed_serialized_len,
             largest_allowed_vec_len,
             largest_allowed_serialized_len,
         ) = max_allocation_is_big_enough(header);
 
+        // The cap is exactly the headers-protocol cap, not derived from message size.
+        // Cast safe: MAX_HEADERS_PER_MESSAGE is the constant 160 (well under u64::MAX).
+        prop_assert!(CountedHeader::max_allocation() == MAX_HEADERS_PER_MESSAGE as u64);
+
         // Check that our smallest_disallowed_vec is only one item larger than the limit
         prop_assert!(((smallest_disallowed_vec_len - 1) as u64) == CountedHeader::max_allocation());
-        // Check that our smallest_disallowed_vec is too big to send as a protocol message
-        prop_assert!(smallest_disallowed_serialized_len > MAX_PROTOCOL_MESSAGE_LEN);
 
         // Check that our largest_allowed_vec contains the maximum number of CountedHeaders
         prop_assert!((largest_allowed_vec_len as u64) == CountedHeader::max_allocation());
+
         // Check that our largest_allowed_vec is small enough to send as a protocol message
+        // (this is now slack: the headers cap is much smaller than the message-size limit).
         prop_assert!(largest_allowed_serialized_len <= MAX_PROTOCOL_MESSAGE_LEN);
     }
 }