Commit b98d7b8
committed
Use
In theory a channel's feerate could be set to some absurd value
(millions of satoshis per vB) and we'd overflow the fee spike
buffer, accepting the absurd fee and ignoring our fee spike buffer
check. This is harmless - the counterparty has much easier ways of
bricking the channel if they want, and paying several BTC in fees
is probably not the best way. Our commitment transaction and dust
fee exposure logic all correctly map the `u32` to a `u64` before
multiplying, making them overflow-safe.
Still, its good to fix overflows because it is a remotely-reachable
crash in debug builds.
Reported by Jordan Mecom of Block's Security Teamsaturating_mul when multiplying feerates by the fee spike buf1 parent 9f73a98 commit b98d7b8
2 files changed
Lines changed: 7 additions & 5 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
5847 | 5847 | | |
5848 | 5848 | | |
5849 | 5849 | | |
5850 | | - | |
| 5850 | + | |
5851 | 5851 | | |
5852 | 5852 | | |
5853 | 5853 | | |
| |||
13333 | 13333 | | |
13334 | 13334 | | |
13335 | 13335 | | |
13336 | | - | |
| 13336 | + | |
| 13337 | + | |
13337 | 13338 | | |
13338 | 13339 | | |
13339 | 13340 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
336 | 336 | | |
337 | 337 | | |
338 | 338 | | |
339 | | - | |
340 | | - | |
| 339 | + | |
| 340 | + | |
341 | 341 | | |
342 | 342 | | |
343 | 343 | | |
344 | | - | |
| 344 | + | |
| 345 | + | |
345 | 346 | | |
346 | 347 | | |
347 | 348 | | |
| |||
0 commit comments