You are affected if:

The read getblocks and read getheaders codec paths accepted block locator vectors up to approximately 65,535 entries (the generic TrustedPreallocate ceiling derived from MAX PROTOCOL MESSAGE LEN), rather than the protocol-specification limit of 101 entries (matching zcashd's MAX LOCATOR SZ). Each entry in the locator vector triggers a per-hash chain lookup (HashMap::contains key + RocksDB::contains hash) in find chain intersection on a tokio blocking-pool thread.

A single maximally-sized getblocks message occupies one blocking-pool thread for approximately 10–65ms. Under sustained load from multiple peers, this can degrade state-read performance for block validation, RPC, and mempool lookups.

The read headers codec path already implements the correct pattern: it reads the CompactSize count, validates against MAX HEADERS PER MESSAGE = 160 before deserialization, and rejects oversized messages. The read getblocks and read getheaders paths were missing this pre-deserialization count check and instead relied on the generic block::Hash::max allocation() bound, which allows (MAX PROTOCOL MESSAGE LEN - 1) / 32 = 65,535 hashes.

A legitimate block locator is logarithmic in chain length (approximately 30 hashes for the current ~3M-block Zcash chain). Zebra's own send-side cap is MAX FIND BLOCK HASHES RESULTS = 500.

The practical impact requires significant attacker bandwidth (approximately 2 MiB per request) and multiple Sybil peers to meaningfully degrade the blocking pool, which limits real-world exploitability.

Patched in Zebra 4.4.2. The fix caps block::Hash::max allocation() at MAX BLOCK LOCATOR LENGTH = 101, matching zcashd's MAX LOCATOR SZ. This causes the deserializer to reject oversized locators before any allocation or iteration occurs.

No specific workaround is needed. Existing backpressure mechanisms (load shedding, sequential per-peer message processing, connection limits) constrain the practical impact.

Under sustained load from multiple Sybil peers, oversized locator vectors can occupy blocking-pool threads and degrade state-read performance. The effect is bounded by connection limits and requires significant attacker bandwidth.

Vulnerability identified by @dingledropper, who submitted the fix in PR #10570. Downstream CPU/blocking-pool impact analysis contributed by @ouicate.