lightningd: fix crash on fixup scan if block unavailable.
What the developer wrote
Authored by Rusty Russell
lightningd: fix crash on fixup scan if block unavailable.
```
lightningd: FATAL SIGNAL 11 (version v25.12rc3-1-g498c5b6)
0x5cc2f620ce4c send_backtrace
common/daemon.c:38
0x5cc2f620cee8 crashdump
common/daemon.c:83
0x7e3ac1e4532f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x5cc2f615f186 fixup_scan_block
lightningd/chaintopology.c:1531
0x5cc2f615c22c getrawblockbyheight_callback
lightningd/bitcoind.c:484
0x5cc2f61aee87 plugin_response_handle
lightningd/plugin.c:701
0x5cc2f61b4043 plugin_read_json
lightningd/plugin.c:790
0x5cc2f6248d8b next_plan
ccan/ccan/io/io.c:60
0x5cc2f624925c do_plan
ccan/ccan/io/io.c:422
0x5cc2f6249319 io_ready
ccan/ccan/io/io.c:439
0x5cc2f624ad24 io_loop
ccan/ccan/io/poll.c:470
0x5cc2f618381a io_loop_with_timers
lightningd/io_loop_with_timers.c:22
0x5cc2f61892ff main
```
This happens intermittantly on in a few tests:
tests/test_invoices.py::test_invoice_botched_migration
tests/test_pay.py::test_pay_bolt11_metadata
tests/test_runes.py::test_id_migration
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: lightningd: potential crash on startup if bitcoind isn't up-to-date.
What changed, and why it matters
This commit fixes a bug where Core Lightning could crash with a segmentation fault (FATAL SIGNAL 11) during startup if the connected Bitcoin node could not provide a requested block. The crash occurred because a function tried to use a block that was not actually loaded. The fix adds a simple check: if the block is missing, log a warning and try again on the next restart instead of crashing.
Apply the patch. It is a small, safe defensive fix. Operators should also ensure their bitcoind is fully synced before starting lightningd to avoid the retry-on-restart loop.
Security signals we found
NULL pointer dereference (SIGSEGV) in startup code path
Crash triggered by missing block data from external Bitcoin backend
Fix adds defensive NULL check in asynchronous callback
Changelog labels this as a fixed potential crash on startup
Evidence from the diff
In lightningd/chaintopology.c, fixup_scan_block() is called as a callback after requesting a block by height. Previously it dereferenced blk without checking for NULL. If the block was unavailable (e.g., bitcoind not fully synced or transient RPC failure), blk was NULL and the function crashed at line 1531. The patch adds a NULL guard at the top of the callback, logs an unusual event, and returns early. The caller will retry on next restart.
Changed components
lightningd/chaintopology.cfixup_scan_block()getrawblockbyheight_callback() in lightningd/bitcoind.cInspect captured patch +8 / −0
diff --git a/lightningd/chaintopology.c b/lightningd/chaintopology.c
index f977dc45..9cb12379 100644
--- a/lightningd/chaintopology.c
+++ b/lightningd/chaintopology.c
@@ -1528,6 +1528,14 @@ static void fixup_scan_block(struct bitcoind *bitcoind,
struct bitcoin_block *blk,
struct chain_topology *topo)
{
+ /* Can't scan the block? We will try again next restart */
+ if (!blk) {
+ log_unusual(topo->ld->log,
+ "fixup_scan: could not load block %u, will retry next restart",
+ height);
+ return;
+ }
+
log_debug(topo->ld->log, "fixup_scan: block %u with %zu txs", height, tal_count(blk->tx));
topo_update_spends(topo, blk->tx, blk->txids, height);
Why this scored 54/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.