]> git.bitcoin.ninja Git - rust-lightning/commit
Fix panic on receiving `channel_ready` after 1st commitment update 2023-01-fix-fast-extra-ready-panic
authorMatt Corallo <git@bluematt.me>
Sun, 8 Jan 2023 00:41:16 +0000 (00:41 +0000)
committerMatt Corallo <git@bluematt.me>
Sun, 8 Jan 2023 02:02:47 +0000 (02:02 +0000)
commit7165d6d48fbb3fcabb81393d7c51b87ea6ced5c6
treee5b0dc6f8f9f22f5bcf875641b3ca22c88bd63be
parentd8a20eda5f74126d96700263716ee3938d4d3c8d
Fix panic on receiving `channel_ready` after 1st commitment update

`cur_counterparty_commitment_transaction_number` starts at
`INITIAL_COMMITMENT_NUMBER`, gets decremented once when the initial
`channel_ready` message is received, and gets decremented a second
time when the first `revoke_and_ack` is received, revoking the
first counterparty commitment point.

At this point, `counterparty_prev_commitment_point` points to the
non-revoked second commitment point.

If we then process a second `channel_ready`, we check the
`cur_counterparty_commitment_transaction_number` number, see that
if is `INITIAL_COMMITMENT_NUMBER - 2` (i.e. not `- 1`) and assume
that the *second* commitment number has been revoked (by
`expect`ing `CounterpartyCommitmentSecrets::get_secret` with
`INITIAL_COMMITMENT_NUMBER - 1`). This `expect` panic's.

As the second commitment point has not yet been revoked, we should
fetch it from `counterparty_prev_commitment_point`, which we do
here, adding a test which failed on the previous code as well.

Found by the `full_stack_target` fuzzer.
lightning/src/ln/channel.rs
lightning/src/ln/priv_short_conf_tests.rs