Modular C implementation of the Lightning Network protocol and node stack.
Every captured commit receives deterministic security triage and a separate communication-quality score. Security candidates and broader second-pass signals receive full-patch Ollama analysis.
Aug 5 → Feb 61049 seen37 candidatesCompleteFeb 6 → Jun 6579 seen10 candidatesCompleteJun 6 → Jul 678 seen1 candidatesCompleteJul 6 → Aug 5147 seen16 candidatesCompleteMessage quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.
Public Git author strings; identities are not independently verified.
Last scanned 51 minutes ago
This commit simply adds a new person's PGP public-key fingerprint to the list of trusted release signers in two documentation files. It does not change any code, fix any bug, or alter any security behavior of the software itself.
41278b4eby jaonoctus+2−02 filesThis is a tiny internal fix to make a bookkeeping migration produce stable event ordering. It changes the timestamp used when creating historical 'deposit' records during a one-time database migration, so the records sort consistently with…
498e5086by daywalker90+2−01 fileThis commit is a documentation-only cleanup of the JSON-RPC command help files. It corrects which numeric error codes are listed for each command so the published schemas match what the software actually returns. No program logic, validati…
d1b6963bby daywalker90+204−1224 filesThis commit fixes a bug where a setting that controls whether unexpected transaction signatures are allowed was not initialized when the channel daemon starts. If a peer sent such signatures before the channel was fully ready, the program …
c09c4520by Erick Cestari+1−01 fileThis commit fixes the project's internal nightly code-coverage CI workflow. It changes how test coverage files are collected, ensures the same LLVM compiler version is used to generate and merge coverage data, and uploads a Codecov-compati…
5685c9a3by cdecker+12−211 fileThis commit is a large cleanup of Core Lightning's API schemas, generated RPC bindings, and related plugin code. The stated goal is to make the documented 'required' fields match what the C code actually always produces or expects. In prac…
ddbd2963by daywalker90+1786−173950 filesThis commit only updates documentation. It adds error code 313 to the documented error lists for several Core Lightning commands (fundpsbt, utxopsbt, txprepare, multiwithdraw, and upgradewallet). The error code already existed in the code …
a34b9758by Peter Neuroth+30−86 filesThis commit fixes a release-script check that verifies the cryptographic signature on a file of checksums. Previously, the script only told GPG to verify the signature file itself. If someone replaced that signature file with an inline-sig…
8e495707by Peter Neuroth+5−21 fileThis commit updates Core Lightning's release documentation to tell users and release managers to run gpg --verify with both the signature file and the manifest file named explicitly. The old one-argument form can silently succeed even if t…
2dee8699by Peter Neuroth+9−62 filesThis commit is a routine update to the Rust dependency lock file (Cargo.lock), bumping many third-party libraries to newer patch or minor versions. The commit message gives no security reason for the update, and no verified references link…
c1551c55by daywalker90+298−2761 fileThis commit fixes a stack-overflow risk in Core Lightning's JSON parser. Before the fix, an attacker could send a valid JSON-RPC message containing thousands of nested brackets or braces. The parser's own helper functions used recursion fo…
83f92e4bby Níckolas Goline+90−22 filesThis commit only fixes typos and comment style. It changes two C-style comments from // to /* */ and corrects a grammar error in a documentation comment ('element' to 'elements'). There are no code behavior changes, no bug fixes, and no se…
273d7f02by w3lld1+3−32 filesThis change fixes a test-infrastructure bug in Core Lightning's Python testing helpers. When running tests against a PostgreSQL database, very long test names could be silently shortened by PostgreSQL, causing different test runs or nodes …
c4fe4cbaby Peter Neuroth+59−12 filesThis fix prevents Core Lightning from trying to use freshly created bitcoins (immature coinbase rewards) as emergency funds for fee-bump transactions. Such a transaction would be invalid under Bitcoin's rules and would be rejected by the n…
34883ff7by cdecker+5−12 filesThis commit fixes a bug in Core Lightning's askrene plugin that could prevent a node from restarting. When a saved routing layer contained a node bias with a description, the plugin accidentally freed the description's memory while using i…
4681177dby Vincenzo Palazzo+2−32 filesThis commit only fixes a test case so it actually exercises the intended code path. It does not change any production code, so it cannot introduce or fix a real-world security vulnerability by itself. The test change is a reproducer for a …
0f3f67a0by Vincenzo Palazzo+3−21 fileThis commit fixes a bug in Core Lightning's experimental dual-funded channel feature. When another node tried to open a channel, Core Lightning was not checking whether the proposed transaction fees were reasonable. A peer could request a …
ba08356fby cdecker+140−04 filesThis commit adds regression tests for three related bugs where wildly wrong Bitcoin transaction feerates could enter Core Lightning. In the worst case, a malicious or broken fee source could make the node think a feerate was zero (due to a…
65bdbc47by cdecker+137−02 filesThis update fixes a crash bug in Core Lightning. When the software tried to list details of a channel opening in progress, it could crash if a stored fee rate was extremely large or zero. The crash happened because the code used an interna…
d67c4936by cdecker+72−227 filesThis commit fixes a bug where Core Lightning nodes could get stuck in a crash loop. If a node had previously stored an extremely high or zero fee rate for an in-progress channel funding operation (a 'splice' or dual-funded channel RBF), a …
f057c692by cdecker+34−01 fileExpand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.
95f1a4c0 · Mar 22, 2026 · 5 filesInformational 17lightningd: explicitly unwatch funding scriptpubkey when channel finally closed.
This is unnecessary now, since we have a destructor, but it'll be important when
we move watching out to `bwatch`.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This change adds an explicit cleanup step that tells the node to stop monitoring the funding transaction once a channel is finally closed. The commit message says this is not strictly needed today because an existing destructor already handles it, but it will matter in a future refactor. There is no direct evidence this fixes an exploitable security bug.
2432cae0 · Mar 22, 2026 · 3 filesInformational 24lightningd: use scriptpubkey, not watch_txid for initial spotting of the funding tx.
funding_depth_cb handled three cases, implicitly:
1. First time we see the funding tx.
2. When we see the funding tx block reorged out.
3. When we see the tx depth increase.
This replaces first one with a scriptpubkey watch. The other two stay
using the watch_txid for now.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This change alters how Core Lightning first detects a channel's funding transaction on the Bitcoin blockchain. Previously it looked for an exact transaction ID; now it watches for any transaction that pays to the channel's expected 2-of-2 multisig script. The commit message frames this as a refactor of the three existing cases handled by the funding-depth callback, not as a security fix. There is no direct evidence in the diff of a vulnerability being patched, but the change could reduce sensitivity to transaction malleability or to cases where the funding transaction ID is not yet known.
669e1024 · Mar 22, 2026 · 6 filesInformational 18lightningd: save short_channel_id in inflight struct as soon as it gets mined.
This also removed the last call to wallet_transaction_locate, so remove that too.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a small internal cleanup change in Core Lightning. It stores a channel identifier (short_channel_id) in memory as soon as a splicing transaction is mined, instead of looking it up from the database every time it is needed. It also removes an unused database helper function. There is no obvious security vulnerability here; it is primarily a code-quality and efficiency improvement.
3b0def41 · Mar 22, 2026 · 8 filesInformational 18common: make encode_scriptpubkey_to_addr take explicit len.
Don't assume it's a tal array: this is useful for dealing with
wally_tx internals.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This change refactors a helper function that turns Bitcoin scriptPubKeys into human-readable addresses. Previously the function measured the length itself using a memory-tracking helper (tal_bytelen). Now callers pass the length explicitly. This is mostly a code-cleanup to support data that isn't tracked by that helper, such as internal libwally transaction buffers. There is no direct security bug being fixed, but the old pattern could theoretically lead to incorrect length handling if a non-tal buffer were passed in future code.
fa35af24 · Mar 22, 2026 · 13 filesInformational 12wallet: remove txfilter.
chaintopology was the only user, so we don't need the txfilter at all.
Remove it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit removes an unused internal transaction filter called txfilter. The code that added wallet addresses and public keys to this filter is deleted because nothing was actually using the filter anymore. There is no indication in the commit that this fixes a security bug; it appears to be ordinary code cleanup.
d63b1e3b · Mar 22, 2026 · 7 filesInformational 23lightningd: use a blockdepth callback instead of a watch_txid.
This is more explicit, and will work far better with an external watcher.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit refactors how Core Lightning tracks the confirmation depth of a channel's funding transaction. Instead of watching a specific transaction ID, it now watches the block height at which the funding transaction was found. The change is described by the author as making the code more explicit and better suited to external blockchain watchers. There is no direct evidence in the commit that this fixes a security vulnerability, but it does touch reorganization handling and could affect how the node reacts when a funding transaction is removed from the blockchain.
ff46af09 · Mar 22, 2026 · 5 filesInformational 15lightningd: remove redundant `txid` arg in depthcb_update_scid.
It's outpoint->txid in all cases.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a small internal cleanup: a function that updates a channel's short identifier was being passed both a transaction ID and a funding outpoint, but the transaction ID is always already part of the outpoint. The change removes the redundant argument and uses the outpoint's own transaction ID instead. There is no security-relevant change.
d871ff3b · Mar 17, 2026 · 1 fileModerate 51splice: RPC error handling fix
Splice commands can fail because of external reasons, for example our peer rejecting the splice. These external reasons eat the active `splice_command` so we need to stop storing the `splice_command` in callbacks and instead pull it from the `splice_commands` list which automatically removes the object when its consumed.
This corrects a lightningd crash under certain RPC circumstances.
Changelog-None
This patch fixes a crash in Core Lightning's lightningd daemon that could occur during splice-related RPC operations. The root cause was that splice command state could be consumed by external failures (like a peer rejecting the splice) while callbacks still held a stale pointer to it. The fix stops storing the splice command pointer inside callback data structures and instead looks it up fresh from the active list when needed, avoiding use-after-free-style crashes.
2566266b · Mar 17, 2026 · 3 filesInformational 20pyln-testing: move mnemonic dependency directly into pyln-testing
When installing only pyln-testing directly it is missing the mnemonic
dependency.
Changelog-None
This commit is a routine packaging fix. It moves a Python library called 'mnemonic' from the main project's dependency list into the dependency list of a smaller sub-package (pyln-testing). This ensures that anyone installing only pyln-testing gets the missing library. There is no security vulnerability or code behavior change here.
09585ee5 · Mar 6, 2026 · 20 filesInformational 15currencyrate: new rust plugin to provide the `currencyconvert` API
Changelog-Added: new plugin currencyrate to provide `currrencyconvert` API
This commit introduces a brand-new optional Rust plugin called 'currencyrate' that adds a currency conversion API to Core Lightning. It also updates generated RPC, gRPC, and configuration schema files to expose the plugin's settings. There is no indication in the commit that this fixes a security bug; it is a feature addition.
51745124 · Feb 28, 2026 · 1 fileInformational 15CI: Speed up 'min-btc-support' by compiling clang with -O3.
It's timing out after 2 hours sometimes: this now make it finish in 53
minutes.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit changes a GitHub Actions CI workflow so that one of the automated test jobs compiles the project with a higher compiler optimization level (-O3) to make the build finish faster and avoid hitting a 2-hour timeout. It does not change any production code, user-facing behavior, or security-sensitive logic.
d73b7564 · Feb 28, 2026 · 1 fileInformational 15CI: Disable flakiness tracking.
287abfbd901616a8c81a02ce366158b4f4630ddf "ci: Add a simple plugin to
report test results to our falkiness tracker" slowed our integration
tests to a crawl: out 6-way gcc integration tests should have taken 20
minutes, but were taking 1hr 24 minutes, and some runs were timing out
altogether.
I cannot reach the server, seems it is down. But tracking flakiness
is rarely useful, so I am disabling this.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit simply turns off a test-reporting feature in the project's automated build system because it was making tests run very slowly and the reporting server appeared to be down. It does not change any wallet, network, or Lightning protocol code, and there is no security issue in the change itself.
572d4db8 · Feb 23, 2026 · 7 filesInformational 15offers: encapsulate globals in plugin_get_data()
This is how modern plugins do it, and it has the benefit of not
requiring extra code for memleak tracking.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is a straightforward internal code cleanup in the Core Lightning 'offers' plugin. It moves several global variables into a single per-plugin data structure and provides a helper function to access them. There is no change to user-facing behavior, no bug fix, and no security-related change described in the commit or diff.
f318c13b · Feb 23, 2026 · 10 filesLow 47db: add STRICT tables with migration for old databases
Enables STRICT tables in developer mode, but old databases (~2019) may
have BLOB values in TEXT columns. Migration converts BLOB faildetail
to TEXT with UTF-8 validation, NULLs invalid data.
STRICT is only applied to fresh databases; existing databases being
upgraded skip STRICT to avoid type affinity issues with legacy data.
Also adds security pragmas in developer mode: trusted_schema=OFF,
cell_size_check=ON.
Fixes #5390.
Changelog-Added: Database: STRICT tables and security pragmas in developer mode
Changelog-Fixed: Database migration for old BLOB-typed faildetail values
This commit hardens Core Lightning's SQLite database handling in developer mode by adding STRICT table enforcement and two security-related SQLite pragmas. It also adds a migration that cleans up old database entries where a text column accidentally stored binary data, converting them to text or wiping them if they aren't valid text. The changes are defensive: they reduce the chance of unexpected data types causing bugs or security issues, but they do not by themselves fix a known exploitable vulnerability.
580c2f78 · Feb 23, 2026 · 8 filesLow 47renepay: refactor and bugfixes
We remove the auxiliary RPC renesenday (only used internally) in favor
of a function that builds the onion, stores the shared secrets
needed to recover the onion reply, and calls sendonion/injectpaymentonion.
This solves a concurrency race
```
**BROKEN** plugin-cln-renepay: Unable to parse sendpay_failure
```
in which we are waiting for renesenday to return in order to record the shared
secrets but we get the a sendpay_failure notification with an onionreply
before we have secrets to decode it.
It also solves a missing JSON id seen in the logs
```
DEBUG plugin-cln-renepay: JSON reply with unknown id
```
because renesendpay was using his command variable to issue an RPC
to sendonion/injecpaymentonion and would fail or succeed the command
before those RPCs were done. This also meant that the callback
functions were silently being ignored.
Changelog-Fixed: renepay: fixes a race condition that leads to **BROKEN** plugin-cln-renepay: Unable to parse sendpay_failure
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
This commit fixes a timing bug in Core Lightning's experimental 'renepay' payment plugin. Previously, the plugin used an internal helper command (renesendpay) to send payment routes. Because of the way commands were chained, the plugin could receive a failure notification with an encrypted onion reply before it had saved the secrets needed to decode that reply. That caused error messages and could prevent the plugin from correctly learning why a payment failed. The fix builds the onion and stores the shared secrets directly before calling sendonion/injectpaymentonion, removing the race condition.
8775b628 · Feb 19, 2026 · 28 filesInformational 15askrene: move routines only accessed by the child process into child/.
We want to make it clear when future generations edit the code, which
routines are called in the child (i.e. all the routing), and which in
the parent.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is a pure code reorganization: it moves several routing-related source files into a new 'child/' subdirectory within the askrene plugin. There are no functional changes, no bug fixes, and no security patches visible in the diff. The code is simply relocated to make it clearer which routines run in the child process versus the parent process.
3e979d1b · Feb 18, 2026 · 2 filesInformational 12pytest: fix bcli tests after sync refactor
Rewrite `test_bitcoin_failure` to reflect synchronous bcli behavior: the node now crashes on invalid bitcoind responses rather than retrying. Add `may_fail` and `broken_log` to handle expected crash.
Update `test_bitcoind_fail_first` stderr check to match the new error message format from `get_bitcoin_result`.
Update test mocks to use proper error format for "block not found".
Co-authored-by: ShahanaFarooqui <shahana.farooqui@gmail.com>
This commit only changes test files. It updates pytest test cases to match new behavior after a code refactor made the lightning node crash instead of retry when it gets invalid responses from the connected Bitcoin node. There is no change to production code, so it does not introduce or fix a security vulnerability by itself.
cd7afb50 · Feb 18, 2026 · 1 fileInformational 15pytest: remove now-invalid test.
Commit 888745be163efe02345e944f7e7d501d64e3744c (dev_disconnect:
remove @ marker.) in v0.11 in April 2022) removed the '@' marker from
our dev_disconnect code, but one test still uses it.
Refactoring this code made it crash on invalid input. The test
triggered a db issue which has been long fixed, so I'm simply removing
it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit simply deletes an outdated test from the test suite. The test used a '@' marker that was removed from the codebase in 2022, so it no longer works. There is no change to production code and no security issue is being fixed.
29e0a1dd · Feb 17, 2026 · 2 filesLow 44bkpr: limp along if we lost our db.
We can't really do decent bookkeeping any more, but don't crash!
```
bookkeeper: plugins/bkpr/recorder.c:178: find_txo_chain: Assertion `acct->open_event_db_id' failed.
bookkeeper: FATAL SIGNAL 6 (version v25.12)
0xaaaab7d51a7f send_backtrace
common/daemon.c:38
0xaaaab7d51b2b crashdump
common/daemon.c:83
0xffff8c0b07cf ???
???:0
0xffff8bdf7608 __pthread_kill_implementation
./nptl/pthread_kill.c:44
0xffff8bdacb3b __GI_raise
../sysdeps/posix/raise.c:26
0xffff8bd97dff __GI_abort
./stdlib/abort.c:79
0xffff8bda5cbf __assert_fail_base
./assert/assert.c:96
0xffff8bda5d2f __assert_fail
./assert/assert.c:105
0xaaaab7d41fd7 find_txo_chain
plugins/bkpr/recorder.c:178
0xaaaab7d421fb account_onchain_closeheight
plugins/bkpr/recorder.c:291
0xaaaab7d37687 do_account_close_checks
plugins/bkpr/bookkeeper.c:884
0xaaaab7d38203 parse_and_log_chain_move
plugins/bkpr/bookkeeper.c:1261
0xaaaab7d3871f listchainmoves_done
plugins/bkpr/bookkeeper.c:171
0xaaaab7d4811f handle_rpc_reply
plugins/libplugin.c:1073
0xaaaab7d4827b rpc_conn_read_response
plugins/libplugin.c:1377
0xaaaab7d889a7 next_plan
ccan/ccan/io/io.c:60
0xaaaab7d88f7b do_plan
ccan/ccan/io/io.c:422
0xaaaab7d89053 io_ready
ccan/ccan/io/io.c:439
```
Fixes: https://github.com/ElementsProject/lightning/issues/8854
Changelog-Fixed: Plugins: `bkpr_listbalances` no longer crashes if we lost our db, then do emergencyrecover and close a channel.
Reported-by: https://github.com/enaples
This commit fixes a crash in Core Lightning's bookkeeper plugin. After a user loses their main database and runs emergency recovery, then closes a channel, the bookkeeper plugin would hit an internal assertion and crash the whole node. The fix makes the plugin log a warning and continue running instead of crashing.
e8fd235d · Feb 16, 2026 · 26 filesInformational 15common: move gossip_store_wire.csv into common/ from gossipd/
It's used by common/gossip_store.c, which is used by many things other than
gossipd. This file belongs in common.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit simply moves a file that defines internal message formats from one directory to another and updates all the references. It is a code reorganization (refactoring) with no functional change to the program's behavior and no security relevance.
b1503098 · Feb 16, 2026 · 1 fileModerate 58pytest: test for crash when we have dying channels and compact the gossip_store.
Before I fixed the handling of dying channels:
```
lightning_gossipd: gossip_store: can't read hdr offset 2362/2110: Success (version v25.12-279-gb38abe6-modded)
0x6537c19ecf3a send_backtrace
common/daemon.c:38
0x6537c19f1a1d status_failed
common/status.c:207
0x6537c19e557a gossip_store_get_with_hdr
gossipd/gossip_store.c:527
0x6537c19e5613 check_msg_type
gossipd/gossip_store.c:559
0x6537c19e5a36 gossip_store_set_flag
gossipd/gossip_store.c:577
0x6537c19e5c82 gossip_store_del
gossipd/gossip_store.c:629
0x6537c19e8ddd gossmap_manage_new_block
gossipd/gossmap_manage.c:1362
0x6537c19e390e new_blockheight
gossipd/gossipd.c:430
0x6537c19e3c37 recv_req
gossipd/gossipd.c:532
0x6537c19ed22a handle_read
common/daemon_conn.c:35
0x6537c19fbe71 next_plan
ccan/ccan/io/io.c:60
0x6537c19fc174 do_plan
ccan/ccan/io/io.c:422
0x6537c19fc231 io_ready
ccan/ccan/io/io.c:439
0x6537c19fd647 io_loop
ccan/ccan/io/poll.c:470
0x6537c19e463d main
gossipd/gossipd.c:609
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit adds a test that reproduces a crash in Core Lightning's gossip daemon. The crash happens when the network's gossip store is compacted while a channel is in a 'dying' state (closing but not yet fully removed). The bug caused internal record offsets to become wrong, leading to a fatal read error and daemon crash. The commit message says the underlying handling was already fixed; this change only adds the regression test.
09781bd3 · Feb 11, 2026 · 2 filesLow 43lightningd: don't assume peer existrs in peer_connected_serialize.
It's always true for the first hook invocation, but if there is more
than one plugin, it could vanish between the two! In the default configuration, this can't happen.
This bug has been around since v23.02.
Note: we always tell all the plugins about the peer, even if it's
already gone.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: lightningd: possible crash when peers disconnected if there was more than one plugin servicing the `peer_connected` hook.
Reported-by: https://github.com/santyr
Fixes: https://github.com/ElementsProject/lightning/issues/8858
This commit fixes a crash bug in Core Lightning's lightningd daemon. When a peer disconnects between two plugin hook invocations, the code could try to read from a peer object that no longer exists, causing a use-after-free style crash. The fix copies the needed peer feature data into the hook payload so it remains valid even if the peer disappears. By default this cannot happen because only one plugin handles the hook, but it becomes possible when more than one plugin is registered.
eaf6fabf · Feb 11, 2026 · 2 filesModerate 59pytest: reproduce crash when node disconnects between hooks:
```
lightningd-2 2026-02-09T00:41:35.196Z TRACE lightningd: Plugin peer_connected_logger_a.py returned from peer_connected hook call
lightningd-2 2026-02-09T00:41:35.196Z TRACE lightningd: Calling peer_connected hook of plugin peer_connected_logger_b.py
lightningd-2 2026-02-09T00:41:35.293Z **BROKEN** lightningd: FATAL SIGNAL 11 (version v25.12-257-g2a5fbd1-modded)
lightningd-2 2026-02-09T00:41:35.293Z **BROKEN** lightningd: backtrace: common/daemon.c:46 (send_backtrace) 0x5b2abd7f29bd
lightningd-2 2026-02-09T00:41:35.293Z **BROKEN** lightningd: backtrace: common/daemon.c:83 (crashdump) 0x5b2abd7f2a0c
lightningd-2 2026-02-09T00:41:35.293Z **BROKEN** lightningd: backtrace: ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0 ((null)) 0x75950d84532f
lightningd-2 2026-02-09T00:41:35.293Z **BROKEN** lightningd: backtrace: lightningd/peer_control.c:1333 (peer_connected_serialize) 0x5b2abd79c964
lightningd-2 2026-02-09T00:41:35.293Z **BROKEN** lightningd: backtrace: lightningd/plugin_hook.c:359 (plugin_hook_call_next) 0x5b2abd7ae14a
lightningd-2 2026-02-09T00:41:35.293Z **BROKEN** lightningd: backtrace: lightningd/plugin_hook.c:299 (plugin_hook_callback) 0x5b2abd7ae38f
lightningd-2 2026-02-09T00:41:35.293Z **BROKEN** lightningd: backtrace: lightningd/plugin.c:701 (plugin_response_handle) 0x5b2abd7a7e28
lightningd-2 2026-02-09T00:41:35.293Z **BROKEN** lightningd: backtrace: lightningd/plugin.c:790 (plugin_read_json) 0x5b2abd7ace9c
lightningd-2 2026-02-09T00:41:35.293Z **BROKEN** lightningd: backtrace: ccan/ccan/io/io.c:60 (next_plan) 0x5b2abd81dada
lightningd-2 2026-02-09T00:41:35.293Z **BROKEN** lightningd: backtrace: ccan/ccan/io/io.c:422 (do_plan) 0x5b2abd81def6
lightningd-2 2026-02-09T00:41:35.293Z **BROKEN** lightningd: backtrace: ccan/ccan/io/io.c:439 (io_ready) 0x5b2abd81dfb3
lightningd-2 2026-02-09T00:41:35.293Z **BROKEN** lightningd: backtrace: ccan/ccan/io/poll.c:470 (io_loop) 0x5b2abd81f0db
lightningd-2 2026-02-09T00:41:35.293Z **BROKEN** lightningd: backtrace: lightningd/io_loop_with_timers.c:22 (io_loop_with_timers) 0x5b2abd77c13b
lightningd-2 2026-02-09T00:41:35.293Z **BROKEN** lightningd: backtrace: lightningd/lightningd.c:1495 (main) 0x5b2abd781c6a
lightningd-2 2026-02-09T00:41:35.293Z **BROKEN** lightningd: backtrace: ../sysdeps/nptl/libc_start_call_main.h:58 (__libc_start_call_main) 0x75950d82a1c9
lightningd-2 2026-02-09T00:41:35.293Z **BROKEN** lightningd: backtrace: ../csu/libc-start.c:360 (__libc_start_main_impl) 0x75950d82a28a
lightningd-2 2026-02-09T00:41:35.293Z **BROKEN** lightningd: backtrace: (null):0 ((null)) 0x5b2abd752964
lightningd-2 2026-02-09T00:41:35.293Z **BROKEN** lightningd: backtrace: (null):0 ((null)) 0xffffffffffffffff
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit adds a new test that reproduces a crash in Core Lightning. The crash happens when a peer disconnects while the lightning node is still waiting for a plugin's 'peer_connected' hook to finish. The test is currently marked as expected to fail, meaning the underlying bug has not been fixed yet in this commit. It is a reproduction test, not a fix.
6a937307 · Feb 3, 2026 · 6 filesInformational 19decode: don't treat every failure as a rune.
If we can't decode something, and it decodes as a rune (and all bech32
strings do!), then we would usually just complain it was a malformed
rune. Be a big more useful, when the parameter looks like somthing else.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: JSON-RPC: `decode` is now more informative with malformed strings (won't claim everything is a malformed rune!).
This commit improves the 'decode' command in Core Lightning so that when it receives a malformed string, it no longer incorrectly labels every failure as a 'malformed rune'. It adds logic to guess the intended type of the input (e.g., a BOLT11 invoice, BOLT12 offer, emergency recovery string, or rune) and returns a more useful error message. There is no direct security vulnerability being fixed; it is a usability and diagnostic improvement.
e2d17cea · Feb 2, 2026 · 1 fileLow 42pytest: test for crash when enableoffer called on a used single-use offer.
Assertion happens here:
newstatus = offer_status_in_db(s | OFFER_STATUS_ACTIVE_F);
Since OFFER_STATUS_SINGLE_F|OFFER_STATUS_USED_F|OFFER_STATUS_ACTIVE_F
is not a valid combination:
```
lightningd-3 2026-01-28T04:45:21.184Z **BROKEN** lightningd: offer_status_in_db: 7 is invalid
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: FATAL SIGNAL 6 (version v25.12-92-g7fff32d-modded)
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: common/daemon.c:83 (crashdump) 0x5a883759dbb7
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0 ((null)) 0x79a2b0c4532f
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ./nptl/pthread_kill.c:44 (__pthread_kill_implementation) 0x79a2b0c9eb2c
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ./nptl/pthread_kill.c:78 (__pthread_kill_internal) 0x79a2b0c9eb2c
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ./nptl/pthread_kill.c:89 (__GI___pthread_kill) 0x79a2b0c9eb2c
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ../sysdeps/posix/raise.c:26 (__GI_raise) 0x79a2b0c4527d
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ./stdlib/abort.c:79 (__GI_abort) 0x79a2b0c288fe
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/log.c:1054 (fatal_vfmt) 0x5a8837509557
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/log.c:1064 (fatal) 0x5a88375095fe
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ./wallet/wallet.h:1451 (offer_status_in_db) 0x5a88375491dc
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: wallet/wallet.c:6160 (offer_status_in_db) 0x5a8837555388
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: wallet/wallet.c:6162 (wallet_offer_enable) 0x5a8837555388
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/offer.c:288 (json_enableoffer) 0x5a8837540939
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/jsonrpc.c:769 (command_exec) 0x5a8837503198
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/jsonrpc.c:910 (rpc_command_hook_final) 0x5a8837503198
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/jsonrpc.c:884 (rpc_command_hook_final) 0x5a8837503198
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/plugin_hook.c:243 (hook_done) 0x5a8837535383
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/plugin_hook.c:343 (plugin_hook_call_next) 0x5a8837535383
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/jsonrpc.c:998 (plugin_hook_call_rpc_command) 0x5a8837503c4f
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/jsonrpc.c:1123 (parse_request) 0x5a8837503c4f
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/jsonrpc.c:1217 (read_json) 0x5a8837503c4f
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ccan/ccan/io/io.c:60 (next_plan) 0x5a88375eca38
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ccan/ccan/io/io.c:422 (do_plan) 0x5a88375eca38
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ccan/ccan/io/io.c:439 (io_ready) 0x5a88375eca38
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ccan/ccan/io/poll.c:470 (io_loop) 0x5a88375eead5
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/io_loop_with_timers.c:22 (io_loop_with_timers) 0x5a8837501f8e
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/lightningd.c:1492 (main) 0x5a88374d3c27
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ../sysdeps/nptl/libc_start_call_main.h:58 (__libc_start_call_main) 0x79a2b0c2a1c9
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ../csu/libc-start.c:360 (__libc_start_main_impl) 0x79a2b0c2a28a
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: (null):0 ((null)) 0x5a88374d5aa4
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: (null):0 ((null)) 0xffffffffffffffff
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit adds a test that exposes a bug in Core Lightning: if you try to re-enable a single-use offer that has already been used, the daemon hits an internal assertion and crashes. The test is marked as expected-to-fail for now, meaning the actual crash is not fixed by this commit—it only documents the failure. A user with RPC access could trigger a denial-of-service by calling enableoffer on a used single-use offer.