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

witnessbeacon: avoid interceptor deadlock

Public commit record

What the developer wrote

Authored by ziggie

58/100 · Thin
witnessbeacon: avoid interceptor deadlock

Release the preimage beacon lock before invoking the on-chain
interceptor. The interceptor path can block on the htlcswitch event
loop, while resolution of another held on-chain HTLC can call back
into the beacon to add a preimage.

If interceptor delivery fails after the subscriber was registered,
cancel the subscription before returning the error.

On-chain held entries are replay handles for the interceptor while
contractcourt waits for a preimage or on-chain expiry. Once the resolver
tears down, keeping the handle until the refund timeout can replay a stale
HTLC to a reconnecting interceptor.

Thread a dedicated cleanup signal from the witness subscription cancel path
back through the interceptable switch event loop. The held set only removes
on-chain entries for that signal, leaving off-chain entries under the link
flow lifecycle.
✓ Descriptive subject✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This patch fixes a deadlock and a stale-data replay problem in LND's 'witness beacon,' the component that notifies external interceptors about HTLCs that might need a preimage. The deadlock occurred because a lock was held while calling into another subsystem that could call back into the same locked code. The stale-replay problem occurred because on-chain HTLC handles were not cleaned up when a subscription was canceled, so a reconnecting interceptor could be replayed an old, already-resolved HTLC. The patch also cancels the subscription if interceptor delivery fails. These are reliability/availability issues with a plausible, though not directly demonstrated, security angle: a stuck node or replayed HTLC could be abused in a Lightning payment-channel attack.

Recommended action

Review the new cancelInterceptor wiring in production deployments and ensure the interceptable switch's RemoveOnChainIntercept correctly synchronizes with the event loop. Monitor for any regressions in HTLC interception behavior. Consider whether the stale-replay scenario could be exploited as a payment-channel griefing vector and assess if additional mitigations are needed.

Security signals we found

01

Deadlock between preimage beacon mutex and htlcswitch interceptor event loop

02

Potential stale on-chain HTLC replay to reconnecting interceptor after resolver teardown

03

Missing cleanup of on-chain intercept handle on subscription cancellation or interceptor failure

04

Lock ordering/callback re-entrancy fix in a security-sensitive preimage-handling path

Risk score

Why this scored 57/100

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