refactor: Return uint64_t from GetSerializeSize
What the developer wrote
Authored by MarcoFalke
refactor: Return uint64_t from GetSerializeSize
Normally, the values are small enough to fit in size_t, but the risk
that it may not fit sometimes is a reason to use uint64_t consistently
for all architectures.
On 64-bit systems, this refactor is a no-op. On 32-bit systems, it could
avoid bugs in the theoretical and unexpected case where a 32-bit size_t
is too small and overflows.
For example, 32-bit Bitcoin Core versions with CVE-2025-46597 unfixed
may overflow while checking for the bad-blk-length violation when
receiving a malformed and bloated compact block.
What changed, and why it matters
This is a small defensive code change in Bitcoin Core that changes an internal size-measuring helper from using the system's native size type (size_t) to always using a 64-bit unsigned integer (uint64_t). On 64-bit computers nothing effectively changes. On 32-bit computers, the change prevents a theoretical integer overflow when calculating the serialized size of very large or malformed data. The commit message mentions this could matter for a specific malformed compact-block handling bug tracked as CVE-2025-46597 on 32-bit builds, but the patch itself only changes the return type and internal variable; it does not fix the compact-block logic directly.
Treat as a hardening/refactor commit. If CVE-2025-46597 is relevant to your deployment, verify that the actual compact-block fix is present separately; this commit alone only widens the size type and does not close the reported vulnerability. Review other commits around the same date for the substantive CVE-2025-46597 fix.
Security signals we found
Integer-width refactor from size_t to uint64_t to avoid 32-bit overflow
Commit message references CVE-2025-46597 and malformed compact-block length handling
Defensive-hardening change rather than direct vulnerability fix
No explicit overflow check or bounds enforcement added in the diff
Evidence from the diff
The patch refactors SizeComputer and GetSerializeSize in src/serialize.h to use uint64_t instead of size_t for accumulated byte counts. It renames nSize to m_size and updates seek(), size(), and GetSerializeSize’s return type. On 64-bit platforms size_t is already 64-bit, so this is a no-op. On 32-bit platforms, size_t is 32-bit, so a serialized-size computation that exceeds 2^32-1 would wrap. The commit message claims this wrapping could affect the bad-block-length check for malformed compact blocks in 32-bit builds that still have CVE-2025-46597 unfixed. The diff itself is purely a type refactor and does not add explicit overflow checks or alter compact-block parsing code.
Changed components
src/serialize.hSizeComputer classGetSerializeSize template function32-bit Bitcoin Core builds (theoretical)Inspect captured patch +11 / −10
diff --git a/src/serialize.h b/src/serialize.h
index e88a25fa..4da48a0b 100644
--- a/src/serialize.h
+++ b/src/serialize.h
@@ -1051,31 +1051,32 @@ struct ActionUnserialize {
class SizeComputer
{
protected:
- size_t nSize{0};
+ uint64_t m_size{0};
public:
SizeComputer() = default;
void write(std::span<const std::byte> src)
{
- this->nSize += src.size();
+ m_size += src.size();
}
- /** Pretend _nSize bytes are written, without specifying them. */
- void seek(size_t _nSize)
+ /** Pretend this many bytes are written, without specifying them. */
+ void seek(uint64_t num)
{
- this->nSize += _nSize;
+ m_size += num;
}
- template<typename T>
+ template <typename T>
SizeComputer& operator<<(const T& obj)
{
::Serialize(*this, obj);
- return (*this);
+ return *this;
}
- size_t size() const {
- return nSize;
+ uint64_t size() const
+ {
+ return m_size;
}
};
@@ -1091,7 +1092,7 @@ inline void WriteCompactSize(SizeComputer &s, uint64_t nSize)
}
template <typename T>
-size_t GetSerializeSize(const T& t)
+uint64_t GetSerializeSize(const T& t)
{
return (SizeComputer() << t).size();
}
Why this scored 45/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.