invoice with a huge expiry crashes or busy-loops lightningd; openchannel_bump on a V1 channel asserts before its own typed errors

[Amperstrand]

Two RPC-reachable daemon failures at current master, both triggerable by a single call from any authenticated RPC client (no peer, no funds movement, no unusual config). Two self-contained commits, each carrying its own regression test.

1. invoice with a far-future expiry — abort or 100% CPU busy-loop

invoice's expiry parameter is an unclamped param_u64, and two ranges of far-future values break the daemon in different ways:

• expiry >= 2^60 needs more bits than push_varlen_field() (common/bolt11.c) can encode in the x field, so bolt11_encode() aborts the whole daemon (FATAL SIGNAL 6). 2^60 - 1, exactly 60 bits, encodes fine.

• Far below that, the invoice expiration timer breaks: install_expiration_timer() (wallet/invoices.c) arms a timer for MIN(expiry_time) - now, but the timer's nanosecond-grain u64 counter (time_to_grains(): tv_sec * 1e6, TIMER_GRANULARITY 1000) overflows for relative delays beyond ~1.845e13 seconds (~584k years). The wrapped timer reads as already due: trigger_expiration() finds nothing expired, re-arms, and the daemon busy-loops at ~100% CPU inside the timers/sqlite churn, with the RPC reply racing the storm (a wedged-but-alive daemon — visible in a backtrace as timer_expired -> trigger_expiration -> expired_ids -> sqlite3).

Fix: refuse at the parameter stage — expiry >= 2^32 seconds (~136 years) returns JSONRPC2_INVALID_PARAMS ("expiry must be below 2^32 seconds (~136 years)"), keeping a wide margin under both limits. 2^32 - 1 still works and is pinned by the test.

2. openchannel_bump on a channel without an RBF inflight — assert(0 > 0)

json_openchannel_bump() computes the BOLT-2 25/24 feerate ramp and asserts next_feerate_min > last_feerate_perkw BEFORE the channel-state gates. channel_last_funding_feerate() returns 0 for a channel without an in-flight funding transaction — every V1 fundchannel channel — so the assert evaluates 0 > 0 and kills the daemon one screen above the honest typed errors ("Channel not eligible to init RBF" / "No inflight for this channel exists") that were written for exactly this call.

Fix: move the ramp computation below the state gates. The assert is then only reached when an inflight exists (so last_feerate_perkw is nonzero by construction) and the existing typed errors become reachable again.

Alternatives considered (for the expiry side)

• Param-stage gate (this PR): smallest blast radius, typed error at the RPC boundary, no timer-layer changes. Chosen because both failure modes share the same "absurd input" root and no legitimate invoice needs >136 years.
• Defensive guard at the timer site: install_expiration_timer() could skip arming when the relative delay exceeds the representable timer range. That would also protect any future caller that feeds a huge delay into the same helper, but it silently leaves invoices unexpired rather than telling the caller their input is absurd, and it touches the timer contract for a single known caller. Happy to add it as belt-and-braces on top if maintainers prefer both.

Tests

• tests/test_invoices.py::test_invoice_expiry_too_large: exact boundary 2^32 - 1 must still work; 2^32 must return -32602 with the daemon alive (getinfo() asserted on every path).
• tests/test_opening.py::test_openchannel_bump_no_inflight: well-formed request against a funded V1 channel must return 312 FUNDING_STATE_INVALID (the pre-existing typed error), daemon alive.

On vanilla master both corners die with FATAL SIGNAL 6; with these commits everything passes, including the adjacent suites: test_invoice_expiry, and the real dual-funded RBF flows test_v2_rbf_single / test_v2_rbf_abort_retry (which exercise the reordered ramp on the legitimate path, run under EXPERIMENTAL_DUAL_FUND=1).

Both sites verified present in current master and in v26.06.6.

Cross-implementation note

lnd, eclair and electrum all return typed errors on caller-induced funding/invoice corners; neither peer implementation aborts the process on RPC input.

Checklist

• The changelog has been updated in the relevant commit(s) according to the guidelines (Changelog-Fixed: trailers).
• Tests have been added or modified to reflect the changes.
• Documentation has been reviewed and updated as needed (no API surface change; new typed refusal errors only).
• Related issues have been listed and linked (none exist upstream for either corner).
• All PRs must consider how to reverse any persistent changes for tools/lightning-downgrade (no persistent/state changes — refusal and reorder only).

[Amperstrand]

Verification update against the v26.06.7 signed release binaries (fresh regtest rig, elementsproject/lightningd:v26.06.7 image, freshly funded V1 channel for the second case), since the source for the emergency release is still embargoed:

• invoice with expiry >= 2^60 still aborts on 26.06.7 — FATAL SIGNAL 6 (version v26.06.7) with abort in the backtrace, daemon dead. So the first commit remains needed even on the latest security release.
• openchannel_bump on a V1 channel is already fixed in 26.06.7: it returns the typed error Can't calculate the next feerate: the last funding feerate recorded for this channel (0) is out of range instead of crashing. Since that fix exists in the release binaries and will presumably reach master when the embargoed source lands, the second commit here is redundant unless you'd like the master-side fix sooner — happy to drop it from this PR if you prefer to let the release fix propagate.

Keeping both commits in place for now; say the word and I'll trim to just the invoice fix.

[Lagrang3]

@Amperstrand, thank you.

Now that you are at it, could you also fix createinvoice? There you can similarly check the expiry bounds
the same way you did with invoice.

[Lagrang3]

@Amperstrand, like you mentioned above. The second commit is not needed, v26.06.7 fixes it already.

[Amperstrand]

Dropped the second commit — v26.06.7's fix supersedes it. The first commit (invoice expiry gate) is unchanged and applies cleanly against current master.

[Amperstrand]

Done — createinvoice applies the same bound now (b179d8f). A crafted bolt11 could carry a huge expiry in past the invoice gate since decode doesn't check signatures; same rejection, same message, checked before the re-encode. The bolt12 path is u32-capped already.