AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
High 72 Bitcoin

tests: regression coverage for out-of-range feerates

Public commit record

What the developer wrote

Authored by cdecker

100/100 · Strong
tests: regression coverage for out-of-range feerates

Three tests, one per way an absurd feerate used to get in or blow up.

test_feerate_ceiling drives the fee source: bcli trims anything wider
than a u32 of perkb to exactly 0xFFFFFFFF, which is also the value whose
+3 wrapped in the perkb->perkw conversion, so a fee source producing an
absurdly *high* feerate used to arrive as 0perkw and get quietly raised
to the floor. It fails without both the widened conversion and the
ceiling.

test_splice_stored_feerate_repaired_on_upgrade plants the poisoned value
on an inflight and then rewinds the db version so the clamping migrations
run over it, which is the upgrade an already-attacked node goes through.
Parametrized over the overflow value in both the form lightningd itself
would have stored it (db_bind_int makes it negative) and the form you get
writing it by hand, plus the zero case and a merely-large one. Asserts
both that the row is repaired and that listpeerchannels -- which used to
abort right here -- agrees.

test_splice_feerate_too_high covers the accepter bound, which did not
previously exist: force_feerate gets us past our own check on what we
will pay, leaving the peer's bound as the thing under test. The RPC
blocks because the splice_ack never comes, hence the thread.

Changelog-None

(cherry picked from commit a609189feeaad80680c35791abad7e1fea66974d)
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit adds regression tests for three related bugs where wildly wrong Bitcoin transaction feerates could enter Core Lightning. In the worst case, a malicious or broken fee source could make the node think a feerate was zero (due to a 32-bit integer overflow), causing transactions to be mined very slowly or not at all. Another bug let an attacker plant an out-of-range feerate in the database, which then crashed the node every time it started because a plugin called listpeerchannels before the RPC was available. A third bug allowed a peer to propose a splice with an absurdly high feerate that the accepting node did not previously reject. The commit only contains tests; the actual fixes are implied to exist in the code the tests exercise.

Recommended action

Review the non-test commits that these regression tests protect (especially the widened conversion, sanity ceiling, database clamping migrations, and accepter-side splice feerate bound) to confirm the fixes are present and correctly implemented. Run the new tests against a build without the fixes to validate they fail as expected. Consider whether additional input validation is needed for feerate parameters in RPC and peer messages.

Security signals we found

01

Integer overflow in feerate conversion (u32 wrap from 0xFFFFFFFF perkb to 0 perkw)

02

Absurd feerate from external fee source bypassing sanity ceiling

03

Database-stored out-of-range feerate causing startup abort/crash loop

04

Missing upper bound on feerate accepted from peer during splicing

05

Regression tests added for three distinct attack/fix paths

Risk score

Why this scored 72/100

Our methodology →
Potential impact 22/30
Exploitability 16/25
Stealth signal 10/15
Affected reach 12/15
Confidence 8/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.