diff options
| author | glozow <gloriajzhao@gmail.com> | 2024-04-22 12:28:53 +0100 |
|---|---|---|
| committer | glozow <gloriajzhao@gmail.com> | 2024-04-22 12:33:06 +0100 |
| commit | ba7c67f609a3d9a6da194d4abb7f8a60934907c3 (patch) | |
| tree | 6928c26fc142614bb5ed7ce5c4e20dbbc2ba421b /doc | |
| parent | 67c0d93982ad214f5e0c9509e9dc3d6d792ad97c (diff) | |
| parent | 016ed248ba0ae64e3f0c93bb47a2cd9b5e49cd85 (diff) | |
| download | bitcoin-ba7c67f609a3d9a6da194d4abb7f8a60934907c3.tar.xz | |
Merge bitcoin/bitcoin#29879: fuzz: explicitly cap the vsize of RBFs for diagram checks
016ed248ba0ae64e3f0c93bb47a2cd9b5e49cd85 fuzz: explicitly cap the vsize of RBFs for diagram checks (Greg Sanders)
Pull request description:
In master we are hitting a case where vsize transactions much larger than max standard size are causing an overflow in not-yet-exposed RBF diagram checking code: https://github.com/bitcoin/bitcoin/pull/29757#issuecomment-2049220195
`ConsumeTxMemPoolEntry` is creating entries with tens of thousands of sigops cost, causing the resulting RBFs to be "overly large".
To fix this I cause the fuzz test to stop adding transactions to the mempool when we reach a potential overflow of `int32_t`.
ACKs for top commit:
glozow:
ACK 016ed248ba0ae64e3f0c93bb47a2cd9b5e49cd85
marcofleon:
ACK 016ed248ba0ae64e3f0c93bb47a2cd9b5e49cd85. I ran libFuzzer on `package_rbf` on the current master branch until the overflow was encountered. Then I built the PR branch and ran the fuzzer using the crash input.
Tree-SHA512: b3ffc98d2c4598eb3010edd58b9370aab1441aafbb1044c83b2b90c17dfe9135b8de9dba475dd0108863c1ffedede443cd978e95231a41cf1f0715629197fa51
Diffstat (limited to 'doc')
0 files changed, 0 insertions, 0 deletions