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

channeldb: fix race condition in link node pruning

Public commit record

What the developer wrote

Authored by ziggie

100/100 · Strong
channeldb: fix race condition in link node pruning

This commit fixes a critical race condition in MarkChanFullyClosed and
pruneLinkNode where link nodes could be incorrectly deleted despite
having pending or open channels.

The race occurred because the check for open channels and the link node
deletion happened in separate database transactions:

Thread A: TX1 checks open channels → [] (empty)
Thread A: TX1 commits
Thread B: Opens new channel with same peer
Thread A: TX2 deletes link node (using stale data)
Result: Link node deleted despite pending channel existing

This creates a TOCTOU (time-of-check to time-of-use) vulnerability where
database state changes between reading the channel count and deleting
the node.

Fix for MarkChanFullyClosed:
- Move link node deletion into the same transaction as the channel
closing check, making the check-and-delete operation atomic

Fix for pruneLinkNode:
- Add double-check within the write transaction to verify no channels
were opened since the caller's initial check
- Maintains performance by keeping early return for common case
- Prevents deletion if channels exist at delete time

This ensures the invariant: "link node exists iff channels exist"
is never violated, preventing database corruption and potential
connection issues.
✓ 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 fixes a database race condition in LND (a Bitcoin Lightning Network implementation). When a channel closed, the software could incorrectly delete stored peer information ('link node') even though a new channel with that same peer had just been opened. The fix moves the 'check for open channels' and 'delete peer info' steps into the same database transaction, so they happen atomically and cannot be interrupted by another operation.

Recommended action

Apply the patch. It is a correctness fix for a race condition that can corrupt the channel/link-node invariant. No immediate incident response is indicated unless operators observe unexplained missing peer records or connection failures after channel closures. Review other database operations for similar split-transaction check/delete patterns.

Security signals we found

01

Race condition / TOCTOU between channel count check and link node deletion

02

Potential database corruption/invariant violation: link node deleted while channel exists

03

Possible connection issues due to missing link node metadata

04

Fix uses atomic transaction to bind check and delete

05

Defensive double-check added inside pruneLinkNode write transaction

Risk score

Why this scored 68/100

Our methodology →
Potential impact 22/30
Exploitability 12/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.