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

Fix race condition causing async payment failure

Public commit record

What the developer wrote

Authored by Valentine Wallace

68/100 · Adequate
Fix race condition causing async payment failure

As the LSP of an async sender, when we receive an update_add with the hold_htlc
flag set, after its onion is decoded we transition the pending HTLC to the
ChannelManager::pending_intercepted_htlcs. However, if we receive the
release_held_htlc message from the receiver *before* we've had a chance to make
this transition, we'll fail to release the HTLC and it will sit in the pending
intercepts map until it is failed backwards.

To fix this race condition, if we receive release_held_htlc from the recipient
we'll not only check the pending_intercepted_htlcs map for the presence of this
HTLC but also check the map where we keep HTLCs prior to their onions being
decoded.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit fixes a timing bug in Lightning Dev Kit's 'async payments' feature. When a payment is held for an offline recipient, the sender's Lightning Service Provider (LSP) normally moves the held HTLC into an internal 'pending intercepts' map after decoding its onion. If the recipient comes online and sends a 'release' message before that move happens, the old code would miss the release instruction and eventually fail the payment backward. The fix makes the release handler also look in the pre-decode map and mark the HTLC to be released as soon as it is ready. The commit adds a regression test and extends the release message format to carry the channel alias and HTLC id needed for that lookup.

Recommended action

Review the locking order between decode_update_add_htlcs and pending_intercepted_htlcs to ensure the new early lookup does not introduce deadlocks. Confirm that adding required TLV fields to ReleaseHeldHtlc does not break compatibility with nodes running older code, and consider whether a feature bit or version gate is needed. Run the new regression test and existing async payment tests.

Security signals we found

01

Race condition in async payment release handling

02

Payment failure / denial-of-service for legitimate async payments

03

New required TLV fields added to ReleaseHeldHtlc context (wire-format change)

04

Regression test added for the race

05

No explicit security advisory or CVE referenced in commit

Risk score

Why this scored 43/100

Our methodology →
Potential impact 12/30
Exploitability 8/25
Stealth signal 6/15
Affected reach 5/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.