What the developer wrote
Authored by Dusty Daemon
splice: Fix log message
Update log message to match the behavior of the check its logging about.
Changelog-None
What changed, and why it matters
This commit fixes a log message in Core Lightning's channel daemon so it correctly lists all three message types the code accepts. It also adds a check during peer reconnection and aborts if an error message is received. The changes are defensive hardening and logging corrections, not a fix for an exploitable security vulnerability.
No immediate security action required. Treat as normal code-quality/robustness patch and include in regular release testing.
Security signals we found
Defensive abort() on WIRE_ERROR in message expectation helper
Added transaction abort check during peer reconnection loop
Log message corrected to reflect actual allowed message types
Evidence from the diff
In channeld.c, peer_expect_msg_three() now prints all three allowed message types in its warning when an unexpected peer message arrives, matching the actual three-way comparison. Additionally, a WIRE_ERROR branch calls abort() before the warning path, and peer_reconnect() now calls check_tx_abort() on each reconnection message. These are robustness improvements; no memory corruption, authentication bypass, or funds-at-risk condition is evident from the diff.
Changed components
channeld/channeld.cpeer_expect_msg_three()peer_reconnect()Inspect captured patch +7 / −1
diff --git a/channeld/channeld.c b/channeld/channeld.c
index 9636008b..b91ee9ae 100644
--- a/channeld/channeld.c
+++ b/channeld/channeld.c
@@ -3031,13 +3031,17 @@ static const u8 *peer_expect_msg_three(const tal_t *ctx,
msg = peer_read(ctx, peer->pps);
type = fromwire_peektype(msg);
+ if (type == WIRE_ERROR)
+ abort();
if (type != expect_type && type != second_allowed_type
&& type != third_allowed_type)
peer_failed_warn(peer->pps, &peer->channel_id,
"Got incorrect message from peer: %s"
- " (should be %s) [%s]",
+ " (should be %s or %s or %s) [%s]",
peer_wire_name(type),
peer_wire_name(expect_type),
+ peer_wire_name(second_allowed_type),
+ peer_wire_name(third_allowed_type),
sanitize_error(tmpctx, msg, &peer->channel_id));
return msg;
@@ -5721,6 +5725,8 @@ static void peer_reconnect(struct peer *peer,
do {
clean_tmpctx();
msg = peer_read(tmpctx, peer->pps);
+ check_tx_abort(peer, msg,
+ inflight ? &inflight->outpoint.txid : NULL);
} while (handle_peer_error_or_warning(peer->pps, msg) ||
capture_premature_msg(&premature_msgs, msg));
Why this scored 15/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.