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

Ensure mutual exclusion in LSPS2/5 persistence

Public commit record

What the developer wrote

Authored by Matt Corallo

68/100 · Adequate
Ensure mutual exclusion in LSPS2/5 persistence

There are various race conditions between `persist` calls on the
LSPS2 and LSPS5 services. Thus, we simply ensure that no two
`persist` calls can be in-flight at the same time, ensuring that
any new state updates between them will ultimately be persisted by
re-persisting from the top in the originally-running `persist` call
if another is started before it finishes.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit fixes race conditions in how two liquidity-service modules (LSPS2 and LSPS5) save their state to disk. Previously, multiple 'persist' operations could run at the same time, which could cause stale or partially-written state to overwrite newer data, or cause a peer's state to be removed incorrectly. The fix adds a simple in-flight flag so only one persist runs at a time, and if new changes arrive during a persist, the process loops around and saves them before finishing.

Recommended action

Treat as a bug-fix commit with potential security relevance for node operators running LSPS2/LSPS5 services. Review whether the atomic counter logic correctly handles spurious wake-ups or panic unwinding that could leave persistence_in_flight non-zero and block future persists. Consider adding tests that interleave persist calls to verify the new mutual-exclusion behavior.

Security signals we found

01

Race condition in persistence path

02

Possible stale-state overwrite or lost peer-state removal

03

Concurrency fix using atomic in-flight marker

04

Re-persist loop to close update window between scan and write

05

No cryptographic or memory-safety bug; availability/consistency issue

Risk score

Why this scored 57/100

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