rpc: tighten setmocktime upper bound to UINT32_MAX
What the developer wrote
Authored by stringintech
rpc: tighten setmocktime upper bound to UINT32_MAX
The previous bound (~year 2262) was too permissive: paths that add an offset to the mocked time (e.g. the future-time check in ContextualCheckBlockHeader) can overflow int64_t (caught by UBSan), and paths that assign it to a uint32_t field (e.g. pblock->nTime in miner.cpp) silently truncate it (caught by the integer sanitizer). UINT32_MAX is the natural ceiling since block header nTime is uint32_t, and mocking beyond it is meaningless for anything consensus-related.
Add setmocktime bound checks to the existing _test_y2106 case in rpc_blockchain.py, and remove the negative bound check from rpc_uptime.py.
What changed, and why it matters
This commit tightens the maximum allowed mock time in Bitcoin Core's testing-only RPC command `setmocktime` from the year 2262 down to the year 2106 (the maximum value a 32-bit unsigned timestamp can hold). The change prevents two types of bugs that can occur only when a developer or tester manually sets an extremely far-future mock time: signed 64-bit integer overflow in time calculations, and silent truncation when the mocked time is copied into a 32-bit block timestamp field. The command is not available in production nodes and cannot be triggered by ordinary network peers, so this is a low-severity hardening fix for a testing tool.
No urgent action required. This is a defensive hardening patch for a testing-only RPC. Operators running regtest/testnet nodes with `setmocktime` should ensure they do not rely on mock times beyond 2106; such usage was already unsupported and could trigger undefined behavior. No network-level mitigation is needed.
Security signals we found
Integer overflow (int64_t) in time arithmetic when offsets are added to an overly large mock time
Silent truncation to uint32_t when mocked time is assigned to block header nTime fields
UBSan/integer sanitizer findings motivating the bound change
Testing-only RPC hardening; not reachable from P2P or production RPC defaults
Evidence from the diff
The setmocktime RPC previously accepted any int64_t value up to std::chrono::nanoseconds::max() expressed in seconds (~2.56 billion seconds, i.e., year ~2262). The commit changes the upper bound to std::numeric_limits<uint32_t>::max() (2^32-1, year 2106). The commit message explains that this is the natural ceiling because consensus block header nTime is uint32_t, and larger mock times can (1) overflow int64_t when offsets are added in paths such as ContextualCheckBlockHeader’s future-time check, and (2) be silently truncated when assigned to uint32_t fields such as pblock->nTime in miner.cpp. The patch also updates functional tests: it adds bound checks to rpc_blockchain.py and removes the now-redundant negative bound check from rpc_uptime.py.
Changed components
src/rpc/node.cpp (setmocktime RPC implementation)test/functional/rpc_blockchain.pytest/functional/rpc_uptime.pyInspect captured patch +6 / −6
diff --git a/src/rpc/node.cpp b/src/rpc/node.cpp
index aad24b0f..74d950ca 100644
--- a/src/rpc/node.cpp
+++ b/src/rpc/node.cpp
@@ -29,6 +29,7 @@
#include <util/time.h>
#include <cstdint>
+#include <limits>
#ifdef HAVE_MALLOC_INFO
#include <malloc.h>
#endif
@@ -61,7 +62,9 @@ static RPCMethod setmocktime()
LOCK(cs_main);
const int64_t time{request.params[0].getInt<int64_t>()};
- constexpr int64_t max_time{Ticks<std::chrono::seconds>(std::chrono::nanoseconds::max())};
+ // block timestamps are uint32_t, so mocking time beyond that is meaningless for anything
+ // consensus-related and can cause integer overflow/truncation issues in time arithmetic.
+ constexpr int64_t max_time{std::numeric_limits<uint32_t>::max()};
if (time < 0 || time > max_time) {
throw JSONRPCError(RPC_INVALID_PARAMETER, strprintf("Mocktime must be in the range [0, %s], not %s.", max_time, time));
}
diff --git a/test/functional/rpc_blockchain.py b/test/functional/rpc_blockchain.py
index bf7c7d11..d731907f 100755
--- a/test/functional/rpc_blockchain.py
+++ b/test/functional/rpc_blockchain.py
@@ -290,6 +290,8 @@ class BlockchainTest(BitcoinTestFramework):
self.log.info("Check that block timestamps work until year 2106")
self.generate(self.nodes[0], 8)[-1]
time_2106 = 2**32 - 1
+ assert_raises_rpc_error(-8, f"Mocktime must be in the range [0, {time_2106}], not -1.", self.nodes[0].setmocktime, -1)
+ assert_raises_rpc_error(-8, f"Mocktime must be in the range [0, {time_2106}], not {time_2106 + 1}.", self.nodes[0].setmocktime, time_2106 + 1)
self.nodes[0].setmocktime(time_2106)
last = self.generate(self.nodes[0], 6)[-1]
assert_equal(self.nodes[0].getblockheader(last)["mediantime"], time_2106)
diff --git a/test/functional/rpc_uptime.py b/test/functional/rpc_uptime.py
index 48256e2f..96c2fcb3 100755
--- a/test/functional/rpc_uptime.py
+++ b/test/functional/rpc_uptime.py
@@ -10,7 +10,6 @@ Test corresponds to code in rpc/server.cpp.
import time
from test_framework.test_framework import BitcoinTestFramework
-from test_framework.util import assert_raises_rpc_error
class UptimeTest(BitcoinTestFramework):
@@ -19,12 +18,8 @@ class UptimeTest(BitcoinTestFramework):
self.setup_clean_chain = True
def run_test(self):
- self._test_negative_time()
self._test_uptime()
- def _test_negative_time(self):
- assert_raises_rpc_error(-8, "Mocktime must be in the range [0, 9223372036], not -1.", self.nodes[0].setmocktime, -1)
-
def _test_uptime(self):
time.sleep(1) # Do some work before checking uptime
uptime_before = self.nodes[0].uptime()
Why this scored 35/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.