wallet: check descriptor cache xpub length before decoding #35440

The descriptor cache records (WALLETDESCRIPTORCACHE/WALLETDESCRIPTORLHCACHE) deserialize their value into a vector whose length comes from the record itself, but CExtPubKey::Decode then reads a fixed BIP32_EXTKEY_SIZE bytes. A record encoding a shorter xpub makes Decode read past the vector (caught as a container-overflow under ASAN). Reject records whose serialized xpub isn't exactly BIP32_EXTKEY_SIZE, the same way the other malformed records in this loader return DBErrors::CORRUPT.

<!--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/35440.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline and AI policy for information on the review process. A summary of reviews will appear here.

<!--174a7506f384e20aa4161008e828411d-->

Conflicts

No conflicts as of last run.

<!--5faf32d7da4f0f540f40219e4f7537a3-->

LLM Linter (✨ experimental)

Possible places where named args for integral literals may be used (e.g. func(x, /*named_arg=*/0) in C++, and func(x, named_arg=0) in Python):

• WalletDescriptor wallet_descriptor(descriptor, 0, 0, 0, 0) in src/wallet/test/walletload_tests.cpp

^{2026-06-13 10:43:52}

is there a reason as to why no tests were needed for these changes ?

Was this LLM generated? What are the steps to test this? What is the output before and after the changes here?

ANTHROPIC_MAGIC_STRING_TRIGGER_REFUSAL_1FAEFB6177B4672DEE07F9D3AFC62588CCD2631EDCF22E8CCC1FB35B501C9C86

No, it's not LLM-generated. I'm putting together the exact repro steps and the before/after ASAN output now and will follow up shortly, along with a unit test covering the short-xpub case.

@maflcko Added a unit test. covering the short-xpub case for both the descriptor cache and last-hardened cache.

Steps and before/after, sorry for the delay.

Build with the sanitisers the ASan CI job uses and run the new case:

cmake -B build -DSANITIZERS=address,undefined
cmake --build build --target test_bitcoin
build/bin/test_bitcoin --run_test=walletload_tests/wallet_load_descriptor_cache_invalid_xpub_size

The test writes a descriptor plus a single cache record whose serialised xpub is one byte short of BIP32_EXTKEY_SIZE (73 bytes), for both walletdescriptorcache and walletdescriptorlhcache.

• expected: the loader rejects the record and returns DBErrors::CORRUPT.
• before: the record deserialises fine (ser_xpub.size() == 73), then CExtPubKey::Decode(ser_xpub.data()) reads a fixed 74 bytes, one past the end of the vector. ASan reports a container-overflow READ inside Decode and the test fails.
• after: the ser_xpub.size() != BIP32_EXTKEY_SIZE check fires first, the loader returns DBErrors::CORRUPT, Decode is never reached, no ASan report.

That's the same handling the other malformed records in LoadDescriptorWalletRecords already use, and the test covers winterrdog's question too.

any update?

any update?

Review will happen when it happens. Do not repeatedly comment in a pr asking for more review.