From dbc37accf79d8a32e40461e1d935a86db2db47e3 Mon Sep 17 00:00:00 2001 From: Matt Corallo Date: Wed, 15 Jan 2025 17:56:36 +0000 Subject: [PATCH] f move 3537 to security --- CHANGELOG.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index b10f11fc2ce..95a1ef79571 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -83,11 +83,6 @@ ## Bug Fixes * Fixed a rare case where a BOLT 12 payment may be made duplicatively if the node crashes while processing a BOLT 12 `invoice` message (#3313). - * Fixed a bug where a counterparty can cause funds of ours to be locked up - by broadcasting a revoked commitment transaction and following HTLC - transactions in specific formats when using an anchor channel. The funds can - be recovered by upgrading to 0.1 and replaying the counterparty's broadcasted - transactions (using `Confirm::transactions_confirmed`) (#3537). * Fixed a bug where a malicious sender could cause a payment `Event` to be generated with an `OfferId` using a payment with a lower amount than the corresponding BOLT 12 offer would have required. The amount in the @@ -159,13 +154,19 @@ will have `balance_msat` equal to `next_outbound_htlc_limit_msat` (#3243). ## Security -0.1 fixes a funds-theft vulnerability when paying BOLT 12 offers. +0.1 fixes a funds-theft vulnerability when paying BOLT 12 offers as well as a +funds-lockup denial-of-service issue for anchor channels. * When paying a BOLT 12 offer, if the recipient responds to our `invoice_request` with an `invoice` which had an amount different from the amount we intended to pay (either from the `offer` or the `amount_msats` passed to `ChannelManager::pay_for_offer`), LDK would pay the amount from the `invoice`. As a result, a malicious recipient could cause us to overpay the amount we intended to pay (#3535). + * Fixed a bug where a counterparty can cause funds of ours to be locked up + by broadcasting a revoked commitment transaction and following HTLC + transactions in specific formats when using an anchor channel. The funds can + be recovered by upgrading to 0.1 and replaying the counterparty's broadcasted + transactions (using `Confirm::transactions_confirmed`) (#3537). * Various denial-of-service issues in the formerly-alpha `lightning-liquidity` crate have been addressed (#3436, #3493).