fuzz: handle BroadcastChannelUpdate in chanmon
What the developer wrote
Authored by Joost Jager
fuzz: handle BroadcastChannelUpdate in chanmon
The regression was introduced in d627ce14c. That change
switched fee update opcodes in chanmon_consistency from
maybe_update_chan_fees() to timer_tick_occurred(), which can
enqueue BroadcastChannelUpdate events while peers are
disconnected.
The harness already tolerated those events in one delivery
path, but still treated them as unreachable in
push_excess_b_events and disconnect draining. Accept
BroadcastChannelUpdate in those match arms so the fuzz target
no longer panics on valid timer tick driven message queues.
AI tools were used in preparing this commit.
What changed, and why it matters
This commit fixes a fuzz-testing harness so it no longer crashes when it encounters a specific kind of routine network message (BroadcastChannelUpdate). The change only affects test code, not the real Lightning node software that users run. It does not fix a vulnerability in production code.
No security action required. Treat as a normal test/QA fix. If tracking fuzz stability, include this patch in fuzzing infrastructure updates.
Security signals we found
Fuzz harness panic fixed
No production code modified
No cryptographic, consensus, or network protocol change
Evidence from the diff
The patch adds MessageSendEvent::BroadcastChannelUpdate handling in three match arms inside fuzz/src/chanmon_consistency.rs. Previously the harness treated these events as unreachable, causing a panic when timer_tick_occurred() enqueued BroadcastChannelUpdate events while peers were disconnected. The underlying production behavior is unchanged; only the fuzz target’s event draining logic is updated.
Changed components
fuzz/src/chanmon_consistency.rsInspect captured patch +3 / −0
diff --git a/fuzz/src/chanmon_consistency.rs b/fuzz/src/chanmon_consistency.rs
index f20f93c..d8d4570 100644
--- a/fuzz/src/chanmon_consistency.rs
+++ b/fuzz/src/chanmon_consistency.rs
@@ -1608,6 +1608,7 @@ pub fn do_test<Out: Output + MaybeSend + MaybeSync>(data: &[u8], out: Out) {
},
MessageSendEvent::SendChannelReady { .. } => continue,
MessageSendEvent::SendAnnouncementSignatures { .. } => continue,
+ MessageSendEvent::BroadcastChannelUpdate { .. } => continue,
MessageSendEvent::SendChannelUpdate { ref node_id, .. } => {
if Some(*node_id) == expect_drop_id { panic!("peer_disconnected should drop msgs bound for the disconnected peer"); }
*node_id == a_id
@@ -1894,6 +1895,7 @@ pub fn do_test<Out: Output + MaybeSend + MaybeSync>(data: &[u8], out: Out) {
MessageSendEvent::SendStfu { .. } => {},
MessageSendEvent::SendChannelReady { .. } => {},
MessageSendEvent::SendAnnouncementSignatures { .. } => {},
+ MessageSendEvent::BroadcastChannelUpdate { .. } => {},
MessageSendEvent::SendChannelUpdate { .. } => {},
MessageSendEvent::HandleError { ref action, .. } => {
assert_action_timeout_awaiting_response(action);
@@ -1916,6 +1918,7 @@ pub fn do_test<Out: Output + MaybeSend + MaybeSync>(data: &[u8], out: Out) {
MessageSendEvent::SendStfu { .. } => {},
MessageSendEvent::SendChannelReady { .. } => {},
MessageSendEvent::SendAnnouncementSignatures { .. } => {},
+ MessageSendEvent::BroadcastChannelUpdate { .. } => {},
MessageSendEvent::SendChannelUpdate { .. } => {},
MessageSendEvent::HandleError { ref action, .. } => {
assert_action_timeout_awaiting_response(action);
Why this scored 17/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.