lightningd: fix bogus memleak report.
What the developer wrote
Authored by Rusty Russell
lightningd: fix bogus memleak report.
We do our own leak detection on a reply from a subd, but the reply
code set subd->conn to NULL (saving it temporarily, in case the subd
is freed), resulting in it being seen as a leak:
```
lightningd-2 2026-01-12T14:11:12.677Z DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-channeld-chan#1: billboard perm: Reconnected, and reestablished.
lightningd-2 2026-01-12T14:11:12.677Z DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-channeld-chan#1: billboard: Channel ready for use. Shutdown messages exchanged.
lightningd-1 2026-01-12T14:11:12.705Z DEBUG 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-closingd-chan#1: pid 100718, msgfd 87
lightningd-1 2026-01-12T14:11:12.705Z DEBUG 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#1: Status closed, but not exited. Killing
...
lightningd-1 2026-01-12T14:11:32.546Z **BROKEN** lightningd: MEMLEAK: 0x55f61eb4d848
lightningd-1 2026-01-12T14:11:32.546Z **BROKEN** lightningd: label=ccan/ccan/io/io.c:92:struct io_conn
lightningd-1 2026-01-12T14:11:32.546Z **BROKEN** lightningd: alloc:
lightningd-1 2026-01-12T14:11:32.840Z **BROKEN** lightningd: ccan/ccan/tal/tal.c:488 (tal_alloc_)
lightningd-1 2026-01-12T14:11:32.845Z **BROKEN** lightningd: ccan/ccan/io/io.c:92 (io_new_conn_)
lightningd-1 2026-01-12T14:11:32.845Z **BROKEN** lightningd: lightningd/subd.c:785 (new_subd)
lightningd-1 2026-01-12T14:11:32.845Z **BROKEN** lightningd: lightningd/subd.c:839 (new_channel_subd_)
lightningd-1 2026-01-12T14:11:32.846Z **BROKEN** lightningd: lightningd/channel_control.c:1714 (peer_start_channeld)
lightningd-1 2026-01-12T14:11:32.847Z **BROKEN** lightningd: lightningd/peer_control.c:1390 (connect_activate_subd)
lightningd-1 2026-01-12T14:11:32.847Z **BROKEN** lightningd: lightningd/peer_control.c:1516 (peer_connected_hook_final)
lightningd-1 2026-01-12T14:11:32.847Z **BROKEN** lightningd: lightningd/plugin_hook.c:243 (hook_done)
lightningd-1 2026-01-12T14:11:32.847Z **BROKEN** lightningd: lightningd/plugin_hook.c:343 (plugin_hook_call_next)
lightningd-1 2026-01-12T14:11:32.847Z **BROKEN** lightningd: lightningd/plugin_hook.c:299 (plugin_hook_callback)
lightningd-1 2026-01-12T14:11:32.851Z **BROKEN** lightningd: lightningd/plugin.c:701 (plugin_response_handle)
lightningd-1 2026-01-12T14:11:32.851Z **BROKEN** lightningd: lightningd/plugin.c:790 (plugin_read_json)
lightningd-1 2026-01-12T14:11:32.851Z **BROKEN** lightningd: ccan/ccan/io/io.c:60 (next_plan)
lightningd-1 2026-01-12T14:11:32.851Z **BROKEN** lightningd: ccan/ccan/io/io.c:422 (do_plan)
lightningd-1 2026-01-12T14:11:32.851Z **BROKEN** lightningd: ccan/ccan/io/io.c:439 (io_ready)
lightningd-1 2026-01-12T14:11:32.851Z **BROKEN** lightningd: ccan/ccan/io/poll.c:470 (io_loop)
lightningd-1 2026-01-12T14:11:32.851Z **BROKEN** lightningd: lightningd/io_loop_with_timers.c:22 (io_loop_with_timers)
lightningd-1 2026-01-12T14:11:32.851Z **BROKEN** lightningd: lightningd/lightningd.c:1492 (main)
lightningd-1 2026-01-12T14:11:32.852Z **BROKEN** lightningd: ../sysdeps/nptl/libc_start_call_main.h:58 (__libc_start_call_main)
lightningd-1 2026-01-12T14:11:32.852Z **BROKEN** lightningd: ../csu/libc-start.c:360 (__libc_start_main_impl)
lightningd-1 2026-01-12T14:11:32.852Z **BROKEN** lightningd: parents:
lightningd-1 2026-01-12T14:11:32.852Z **BROKEN** lightningd: lightningd/lightningd.c:108:struct lightningd
lightningd-1 2026-01-12T14:11:32.853Z DEBUG lightningd: channel_gossip: no longer in startup mode
lightningd-1 2026-01-12T14:11:32.856Z DEBUG hsmd: new_client: 1
```
The workaround is to do our own leak detection on a timer (making the
conn notleak() would leave us open to a real leak in future!).
We also move the `struct leak_detect` definition inside the C file
where it belongs.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
What changed, and why it matters
This commit fixes a false alarm in Core Lightning's internal memory-leak checker. When the node asked a sub-process to report its memory usage, the reply handling briefly set aside a connection pointer, making the leak detector wrongly report that connection as leaked. The fix delays the final leak check until after the reply handling is finished, so the temporary pointer state is no longer visible. It is a diagnostic/robustness fix, not a security vulnerability fix, and does not create a way for an attacker to exploit the node.
Treat as a normal bugfix / diagnostic improvement. No urgent security action is required. Operators and developers may notice fewer spurious MEMLEAK log entries after upgrading. If running a node, apply the patch through the usual release process.
Security signals we found
False-positive memory-leak report caused by transient pointer state during subdaemon reply handling
Fix uses deferred timer rather than marking the connection notleak(), explicitly to avoid hiding a real future leak
No input validation, parsing, cryptographic, or authorization changes
No externally reachable attack surface introduced or removed
Evidence from the diff
The memleak RPC in lightningd sends requests to subdaemons and, when all replies are in, calls finish_report() to scan for tal allocations that look leaked. The reply callback (leak_detect_req_done) was invoked while subd->conn was temporarily saved and set to NULL; the subsequent finish_report() then saw that struct io_conn as an unreachable allocation and reported a MEMLEAK. The patch defers finish_report() via a zero-timeout relative timer so the subd reply path completes and subd->conn is restored before the scan runs. It also moves struct leak_detect from the header into the C file and adds an ld pointer so the timer can be created.
Changed components
lightningd/memdump.clightningd/memdump.hlightningd/subd.c (interacting code referenced in log backtrace, not modified)Inspect captured patch +16 / −8
diff --git a/lightningd/memdump.c b/lightningd/memdump.c
index cbd1b31d..6c915707 100644
--- a/lightningd/memdump.c
+++ b/lightningd/memdump.c
@@ -16,6 +16,13 @@
#include <lightningd/memdump.h>
#include <lightningd/subd.h>
+struct leak_detect {
+ struct command *cmd;
+ struct lightningd *ld;
+ size_t num_outstanding_requests;
+ const char **leakers;
+};
+
static void json_add_ptr(struct json_stream *response, const char *name,
const void *ptr)
{
@@ -162,8 +169,13 @@ static void leak_detect_req_done(const struct subd_req *req,
struct leak_detect *leak_detect)
{
leak_detect->num_outstanding_requests--;
- if (leak_detect->num_outstanding_requests == 0)
- finish_report(leak_detect);
+ if (leak_detect->num_outstanding_requests == 0) {
+ /* We do this off a timer: doing it off a subd reply makes us think that the
+ * subd->conn (temporarily set to NULL during the cb) is a leak! */
+ new_reltimer(leak_detect->ld->timers, leak_detect,
+ time_from_sec(0),
+ finish_report, leak_detect);
+ }
}
/* Start a leak request: decrements num_outstanding_requests when freed. */
@@ -230,6 +242,7 @@ static struct command_result *json_memleak(struct command *cmd,
return command_check_done(cmd);
leaks = tal(cmd, struct leak_detect);
+ leaks->ld = cmd->ld;
leaks->cmd = cmd;
leaks->num_outstanding_requests = 0;
leaks->leakers = tal_arr(leaks, const char *, 0);
diff --git a/lightningd/memdump.h b/lightningd/memdump.h
index 8ce39fd2..07a628b7 100644
--- a/lightningd/memdump.h
+++ b/lightningd/memdump.h
@@ -3,15 +3,10 @@
#include "config.h"
struct command;
+struct leak_detect;
struct subd;
struct subd_req;
-struct leak_detect {
- struct command *cmd;
- size_t num_outstanding_requests;
- const char **leakers;
-};
-
/* Start a leak request: decrements num_outstanding_requests when freed. */
void start_leak_request(const struct subd_req *req,
struct leak_detect *leak_detect);
Why this scored 19/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.