gossipd: don't accept malformed channel_announcements with mis-ordered node-ids.
What the developer wrote
Authored by Rusty Russell
gossipd: don't accept malformed channel_announcements with mis-ordered node-ids.
See https://github.com/lightning/bolts/pull/1333
Every reader of the gossip_store gets upset, and we get many errors if this happens :(
Reported-by: https://github.com/NishantBansal2003
Changelog-Fixed: Protocol: We correctly reject invalidly ordered channel_announcement messages.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
What changed, and why it matters
This update fixes a bug in Core Lightning's gossip daemon, which handles network routing announcements. The daemon was accepting malformed channel announcements where the two node IDs were in the wrong order. Such messages are invalid per the Lightning protocol and can cause errors for any node that later reads them from its stored gossip data. The fix makes the node reject these invalid announcements, preventing downstream error cascades.
Apply the patch and consider rebuilding or pruning gossip_store entries that may already contain malformed channel_announcements, since existing bad records can still trigger errors on read even after the fix.
Security signals we found
Malformed protocol message accepted as valid
Spec-violating input propagated to persistent store
Downstream error cascade on gossip_store read
Denial-of-service-like symptom via gossip store corruption
BOLT specification compliance fix
Evidence from the diff
The patch adds a validation check in gossipd/gossmap_manage.c’s gossmap_manage_channel_announcement() to enforce BOLT #7 ordering: node_id_1 must be lexicographically less than node_id_2. Previously, this check was missing, so malformed channel_announcement messages with mis-ordered node IDs were accepted. Once stored in gossip_store, every reader (including the local node on restart) would encounter the bad record and emit errors. The fix returns an error string and ignores the message when ordering is violated.
Changed components
gossipd/gossmap_manage.cgossip_store persistencechannel_announcement validationInspect captured patch +14 / −0
diff --git a/gossipd/gossmap_manage.c b/gossipd/gossmap_manage.c
index 4cedf211..eee55a15 100644
--- a/gossipd/gossmap_manage.c
+++ b/gossipd/gossmap_manage.c
@@ -648,6 +648,20 @@ const char *gossmap_manage_channel_announcement(const tal_t *ctx,
tal_hex(tmpctx, announce));
}
+ /* BOLT-gossip-node-check #7:
+ * The receiving node:
+ *...
+ * - if `node_id_1` is not lexicographically less than `node_id_2`:
+ * - SHOULD send a `warning`.
+ * - MAY close the connection.
+ * - MUST ignore the message.
+ */
+ if (!(node_id_cmp(&node_id_1, &node_id_2) < 0)) {
+ return tal_fmt(ctx, "node_id_1 must be the lesser node id! 1=%s, 2=%s",
+ fmt_node_id(tmpctx, &node_id_1),
+ fmt_node_id(tmpctx, &node_id_2));
+ }
+
/* If a prior txout lookup failed there is little point it trying
* again. Just drop the announcement and walk away whistling.
*
Why this scored 52/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.