Reject out-of-range push_asset_amount in handle_funding

[0xaudron]

handle_funding computes the acceptor side RGB split as remote_rgb_amount = channel_rgb_amount - push_amount, where push_amount comes from the counterparty supplied push_asset_amount in open_channel. The value is not validated against channel_rgb_amount.

When a peer sends push_asset_amount greater than the funded asset amount the subtraction underflows. Release builds have overflow checks off, so the value wraps. The wrapped remote_rgb_amount is then passed to color_psbt, which returns InvalidColoringInfo, and the result is unwrapped. The panic poisons the channel manager mutex and the node stops serving channel operations until it is restarted.

The initiator side already rejects this in rgb-lightning-node before sending but the acceptor cannot rely on the counterparty running that check.

Fix: Reject push_amount > channel_rgb_amount in handle_funding before the subtraction, using the existing ChannelError::close path.

[zoedberg]

Thank you! Could you add a test in RLN to prove the attack?

[0xaudron]

Sure, btw would you prefer

• integration test for the PoC which willl require me to push changes to RLN repo separately
• unit test which will settle new push to rust-ligntning repo

[zoedberg]

Since we have a long-term plan to drop the LDK fork (by introducing the required flexibility upstream), we do not run or write unit tests there. So please write an integration test in RLN.

[0xaudron]

Opened a pull request in RLN: RGB-Tools/rgb-lightning-node#138

[zoedberg]

Thank you, LGTM. But please rebase this on top of the updated rgb branch tip