lightningd: fix segfault when parse_filter fails
What the developer wrote
Authored by dovgopoly
lightningd: fix segfault when parse_filter fails
We need to initialize ->json_cmd *before* complaining about malformed
filters.
```
lightningd: FATAL SIGNAL 11 (version v25.12-21-g3851187-modded)
0x1042d2023 ???
send_backtrace+0x4f:0
0x1042d20cb ???
crashdump+0x43:0
0x19fe3b743 ???
???:0
0x104180173 command_log
lightningd/jsonrpc.c:1406
0x10420d8f7 command_fail_badparam
common/json_command.c:25
0x104181a07 parse_request
lightningd/jsonrpc.c:1075
0x104181a07 read_json
lightningd/jsonrpc.c:1216
0x10424c65b next_plan
ccan/ccan/io/io.c:60
0x10424c65b do_plan
ccan/ccan/io/io.c:422
0x10424c587 io_ready
ccan/ccan/io/io.c:439
0x10424dd9b io_loop
ccan/ccan/io/poll.c:470
0x10417ede7 io_loop_with_timers
lightningd/io_loop_with_timers.c:22
0x104183a33 main
lightningd/lightningd.c:1492
```
Co-authored-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: JSON-RPC: malformed filters no longer crash lightningd.
What changed, and why it matters
This commit fixes a bug where a malformed JSON-RPC filter could crash the Core Lightning daemon (lightningd) with a segmentation fault. The crash happened because the code tried to report the malformed filter before it had looked up the command it was processing. The fix moves the command lookup earlier, so the error can be reported safely without dereferencing a null pointer.
Apply the patch. It is a small, targeted fix with a clear crash reproduction. Nodes accepting JSON-RPC connections (especially from untrusted or buggy clients) should upgrade to avoid denial-of-service crashes. No additional mitigation is required beyond patching.
Security signals we found
NULL pointer dereference leading to daemon crash (DoS)
Use-after-initialization ordering bug in JSON-RPC request parsing
Crash triggered by malformed user-supplied RPC filter parameter
Changelog explicitly labels this as a JSON-RPC crash fix
Evidence from the diff
In parse_request(), parse_filter() could call command_fail_badparam(), which eventually calls command_log(). command_log() dereferences c->json_cmd, but c->json_cmd was only initialized after parse_filter() returned. If parse_filter() failed, c->json_cmd was NULL, causing a NULL pointer dereference and SIGSEGV. The fix moves the find_cmd() assignment (and the unknown-command check) before the parse_filter() call, ensuring c->json_cmd is valid before any path that may log the command.
Changed components
lightningd/jsonrpc.cparse_request()parse_filter()command_log()command_fail_badparam()Inspect captured patch +7 / −6
diff --git a/lightningd/jsonrpc.c b/lightningd/jsonrpc.c
index 7240fdc9..dbd7fd84 100644
--- a/lightningd/jsonrpc.c
+++ b/lightningd/jsonrpc.c
@@ -1070,6 +1070,13 @@ parse_request(struct json_connection *jcon,
"Expected string for method");
}
+ c->json_cmd = find_cmd(jcon->ld->jsonrpc, buffer, method);
+ if (!c->json_cmd) {
+ return command_fail(
+ c, JSONRPC2_METHOD_NOT_FOUND, "Unknown command '%.*s'",
+ method->end - method->start, buffer + method->start);
+ }
+
if (filter) {
struct command_result *ret;
ret = parse_filter(c, "filter", buffer, filter);
@@ -1081,12 +1088,6 @@ parse_request(struct json_connection *jcon,
* actually just logging the id */
log_io(jcon->log, LOG_IO_IN, NULL, c->id, NULL, 0);
- c->json_cmd = find_cmd(jcon->ld->jsonrpc, buffer, method);
- if (!c->json_cmd) {
- return command_fail(
- c, JSONRPC2_METHOD_NOT_FOUND, "Unknown command '%.*s'",
- method->end - method->start, buffer + method->start);
- }
if (!command_deprecated_in_ok(c, NULL,
c->json_cmd->depr_start,
c->json_cmd->depr_end)) {
Why this scored 72/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.