signet: Fix uninitialized read in validation#20035
Conversation
|
Too sad that teaching the compiler to warn about this would make the code massively verbose, but maybe it is worth a shot now that this is the second time this year? |
|
Concept ACK The parameters |
|
unit256 are default initialized to all-zeros |
Right, in those case there is no uninitialized read. Still, looking at mainnet, testnet and regtest, without exception all parameters (i.e. all 22 fields of
|
|
@MarcoFalke Nice catch! How did you find this one? It's always a bit sad to see unitialized reads enter our code base without being caught automatically at CI stage by either dynamic analysis (MSAN or Valgrind) or static analysis :( |
|
The UUM takes place in |
|
Unfortunately it seems like this UUM is not triggered by the code paths exercised by |
faff676 to
fa82143
Compare
|
Pushed some non-bugfix changes |
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsNo conflicts as of last run. |
kallewoof
left a comment
There was a problem hiding this comment.
re-ACK. Agree with moving chain work / assume valid comments.
|
@kallewoof @MarcoFalke Have someone investigated why this UUM appear not to be exercised in the functional tests? |
|
@practicalswift @MarcoFalke I made a minimal test that fails on master: https://github.com/kallewoof/bitcoin/tree/202010-signet-uuv-min9-test The test succeeds on top of this PR. |
|
The versionbits condition isn't evaluated for the first retarget period after the genesis block, so no test hits it. |
theStack
left a comment
There was a problem hiding this comment.
ACK fa82143e41c067e7d16d612c775701be94974d54 🩹
jonatack
left a comment
There was a problem hiding this comment.
fa82143e maybe also change
--- a/src/chainparams.cpp
+++ b/src/chainparams.cpp
@@ -365,7 +365,7 @@ public:
consensus.nSubsidyHalvingInterval = 150;
consensus.BIP16Exception = uint256();
consensus.BIP34Height = 500; // BIP34 activated on regtest (Used in functional tests)
- consensus.BIP34Hash = uint256();
+ consensus.BIP34Hash = uint256{};|
Great find -- LGTM modulo the two comments |
promag
left a comment
There was a problem hiding this comment.
Code review ACK fa82143e41c067e7d16d612c775701be94974d54.
|
Code review ACK fa82143e41c067e7d16d612c775701be94974d54 |
|
It was found by reading/reviewing the code |
|
Concept ACK, Approach ACK Haven't looked into @kallewoof test but presumably that will be in a follow up PR. Thanks for sharing resources too @practicalswift. Added to a StackExchange post. |
|
ACK fa82143e41c067e7d16d612c775701be94974d54: diff looks correct |
|
Sorry, needs rebase (probably with taproot changes) |
fa82143 to
fa60f0d
Compare
|
Rebased |
kallewoof
left a comment
There was a problem hiding this comment.
Typo in 3rd commit message (unit256).
fa60f0d to
fa723e3
Compare
|
Fixed typo in commit msg |
|
re-ACK fa723e3: patch still looks correct |
fa723e3 Initialize default-initialized uint256 consensus params to zero explicitly (MarcoFalke) fa729cd doc: Move assumed-values doxygen comments to header (MarcoFalke) fa64892 signet: Fix uninitialized read in validation (MarcoFalke) Pull request description: ACKs for top commit: practicalswift: re-ACK fa723e3: patch still looks correct kallewoof: ReACK fa723e3 theStack: re-ACK fa723e3 🍐 Tree-SHA512: db562bcc15af23bbcbf485f0bbf7564c64c144a4368230fd7682e8861d9500f6f5240351e31c560140df43b2e8456eafd9d27d1e8dd682b20afcc279a39dc329
No description provided.