net: reject oversized locators before allocating #35936

Problem: getblocks and getheaders enforce MAX_LOCATOR_SZ only after deserializing locator hashes. A truncated locator advertising an oversized count makes generic vector deserialization fail before the disconnect check, leaving the peer connected.

Fix: Read the advertised count before allocating hashes and disconnect when it exceeds the existing limit. Catch only the size-limit error so other deserialization failures remain non-disconnecting. Complete oversized locators continue to disconnect without discouragement, and p2p_invalid_locator.py preserves the established boundary: both messages accept 101 hashes and disconnect at 102.

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--006a51241073e994b41acfe9ec718e94-->

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/35936.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline and AI policy for information on the review process.

If your review is incorrectly listed, please copy-paste <code>&lt;!--meta-tag:bot-skip--&gt;</code> into the comment that the bot should ignore.

<!--5faf32d7da4f0f540f40219e4f7537a3-->

<!--85328a0da195eb286784d51f73fa0af9-->

🚧 At least one of the CI tasks failed. _{Task iwyu: https://github.com/bitcoin/bitcoin/actions/runs/31227149534/job/93023654808} _{LLM reason (✨ experimental): CI failed because IWYU reported a headers/include issue (generated “Failure generated from IWYU” and exited non-zero on src/primitives/block.h).}

<details><summary>Hints</summary>

Try to run the tests locally, according to the documentation. However, a CI failure may still happen due to a number of reasons, for example:

• Possibly due to a silent merge conflict (the changes in this pull request being incompatible with the current code in the target branch). If so, make sure to rebase on the latest commit of the target branch.

• A sanitizer issue, which can only be found by compiling with the sanitizer and running the affected test.

• An intermittent issue.

Leave a comment here, if you need help tracking down a confusing failure.

</details>

Approach ACK. The dedicated exception subtype is the right shape, and the truncated case it targets is fixed.

The same message still leaves the peer connected once the count goes above MAX_SIZE. LIMITED_VECTOR only sees counts that ReadCompactSize accepts, and ReadCompactSize range-checks against MAX_SIZE first, throwing a plain std::ios_base::failure, so a locator advertising more than 33554432 hashes reaches the generic handler in ProcessMessages. I ran your test with COMPACTSIZE(uint64_t{MAX_SIZE} + 1) in place of COMPACTSIZE(MAX_SIZE / sizeof(uint256)): getblocks and getheaders both end with fDisconnect false on 725bf357d9ef652eacd809a1bf2f6f79ec73a0b4. Both counts are the same 5 bytes on the wire.

Reading the count without the range check makes Limit the only bound, and that case disconnects too:

-        size_t size = ReadCompactSize(s);
+        const uint64_t size{ReadCompactSize(s, /*range_check=*/false)};
         if (size > Limit) {
             throw LimitedVectorExceededError{size};
         }
-        v.reserve(size);
+        v.reserve(static_cast<size_t>(size));

m_size has to widen to uint64_t with it, since size_t truncates on the 32-bit builds. With that applied the unit suite, p2p_invalid_locator.py and p2p_invalid_messages.py pass.

Reverting only src/net_processing.cpp to 1f53cab and keeping the new test makes net_tests/oversized_locator_handling fail on node.fDisconnect for both message types.

I have tested the code on your head merged onto master 128456b.

Is the case above MAX_SIZE out of scope here on purpose?

Untested, but looks fine to me.