Return an error when the intercept SCID is unknown to the LSPS2 service
What the developer wrote
Authored by Willem Van Lint
Return an error when the intercept SCID is unknown to the LSPS2 service
HTLCs can be intercepted for multiple reasons unrelated to this handler:
- Other HTLC interceptors might have generated intercept SCIDs.
- The SCID of a closed channel might have fallen into the fake SCID
namespace.
The LSPS2 handler needs to indicate whether the specific SCID was known
to it, so other handlers can be called or the HTLC can be failed back.
What changed, and why it matters
This change fixes a logic bug in the LSPS2 liquidity service of rust-lightning. Previously, when an intercepted HTLC carried a short channel ID (SCID) that the LSPS2 service did not recognize, the handler silently did nothing. Now it returns a clear error so the caller can route the HTLC to another handler or fail it back. The fix prevents HTLCs from getting stuck or being silently dropped when multiple interceptors are active or when old SCIDs overlap with the fake SCID namespace.
Treat as a low-severity correctness fix. Review callers of the LSPS2 service handler to ensure they properly propagate or handle the returned APIError, especially when multiple HTLC interceptors are registered. No immediate emergency response is warranted, but the fix should be included in the next maintenance release.
Security signals we found
HTLC interception handler silently dropped unknown SCIDs before patch
Multiple interceptors or fake/closed-channel SCID collisions could cause HTLCs to stall
Patch adds explicit error return for unknown intercept SCID
No cryptographic or memory-safety issue; this is a protocol-handling correctness fix
Evidence from the diff
In lightning-liquidity/src/lsps2/service.rs, the HTLC interception handler now returns APIError::APIMisuseError with message ‘Unknown scid provided: {intercept_scid}’ when the intercept SCID is not known to the LSPS2 service. Before, the code fell through silently after the match on the SCID lookup, which could leave the HTLC unhandled. The change is defensive: it signals to the caller that this handler cannot process the HTLC, allowing proper fallback or failure handling.
Changed components
lightning-liquidity/src/lsps2/service.rsLSPS2 service HTLC interception handlerInspect captured patch +5 / −1
diff --git a/lightning-liquidity/src/lsps2/service.rs b/lightning-liquidity/src/lsps2/service.rs
index 9bb3ded..7d7d75b 100644
--- a/lightning-liquidity/src/lsps2/service.rs
+++ b/lightning-liquidity/src/lsps2/service.rs
@@ -981,7 +981,7 @@ where
/// Will generate a [`LSPS2ServiceEvent::OpenChannel`] event if the intercept scid matches a payment we are expected
/// and the payment amount is correct and the offer has not expired.
///
- /// Will do nothing if the intercept scid does not match any of the ones we gave out.
+ /// Will return an error if the intercept scid does not match any of the ones we gave out.
///
/// [`Event::HTLCIntercepted`]: lightning::events::Event::HTLCIntercepted
/// [`LSPS2ServiceEvent::OpenChannel`]: crate::lsps2::event::LSPS2ServiceEvent::OpenChannel
@@ -1067,6 +1067,10 @@ where
});
},
}
+ } else {
+ return Err(APIError::APIMisuseError {
+ err: format!("Unknown scid provided: {}", intercept_scid),
+ });
}
if let Some(counterparty_node_id) = should_persist {
Why this scored 34/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.