channeld: accepts tx_init_rbf after peer sent splice_locked #9570

BOLT 2 requires the receiver of tx_init_rbf to reject it when the sender has already sent splice_locked:

The receiving node:

• ...
• If the sender previously sent splice_locked:
  • MUST send a warning and close the connection or send an error
    and fail the channel.

CLN does not enforce this. When the peer sends splice_locked and then tx_init_rbf, CLN accepts the RBF and starts a new interactive-tx session.

Where

handle_peer_splice_locked() (channeld/channeld.c:567) records the peer's splice_locked via implied_peer_splice_locked(), which sets peer->splice_state->remote_locked_txid.

splice_accepter() (channeld/channeld.c:4272), the WIRE_TX_INIT_RBF branch, gates the RBF only on: a pending inflight existing (last_inflight), STFU being active, the channel_id matching, and the feerate being in range. It never consults remote_locked_txid, so an RBF that arrives after the peer's splice_locked is accepted. remote_locked_txid is read only in check_mutual_splice_locked(), never in the RBF gate.

Impact

Low. No funds at risk: the RBF still runs through check_balances() and the normal signing flow, and nothing invalid is signed. The peer is contradicting itself (it said a splice was locked, then asked to replace it), which a correct receiver rejects up front; CLN instead proceeds, wasting a round trip and leaving the channel quiesced longer. This is a spec-compliance / robustness gap.

Fix

In the WIRE_TX_INIT_RBF branch of splice_accepter(), if peer->splice_state->remote_locked_txid is set, peer_failed_warn() instead of proceeding.

Discovery

Found while fuzzing splicing with smite.