lightningd: test for very long log entries
What the developer wrote
Authored by Lagrang3
lightningd: test for very long log entries
We were using vasprintf to generate the log line and then using free to
deallocate the string. However, in the case of a very long log line
a new pointer was created with tal_fmt and then tried to use free on it.
This was introduced in commit: 4d8f923a9a1468b8987dbb48e8fc988747f8c62f
```
free(): invalid pointer
lightningd: FATAL SIGNAL 6 (version v26.06-21-gebc5dc2)
0x563dab20be43 send_backtrace
common/daemon.c:38
0x563dab20becd crashdump
common/daemon.c:83
0x7f0cf0c96def ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x7f0cf0ceb95c __pthread_kill_implementation
./nptl/pthread_kill.c:44
0x7f0cf0c96cc1 __GI_raise
../sysdeps/posix/raise.c:26
0x7f0cf0c7f4ab __GI_abort
./stdlib/abort.c:77
0x7f0cf0c80290 __libc_message_impl
../sysdeps/posix/libc_fatal.c:134
0x7f0cf0cf5464 malloc_printerr
./malloc/malloc.c:5832
0x7f0cf0cfa41b _int_free_check
./malloc/malloc.c:4560
0x7f0cf0cfa41b _int_free
./malloc/malloc.c:4692
0x7f0cf0cfa41b __GI___libc_free
./malloc/malloc.c:3476
0x563dab19be60 logv
lightningd/log.c:688
0x563dab19c0bc log_
lightningd/log.c:728
0x563dab1c1047 plugin_log_handle
lightningd/plugin.c:530
0x563dab1c5801 plugin_notification_handle
lightningd/plugin.c:609
0x563dab1c5a9a plugin_read_json
lightningd/plugin.c:753
0x563dab2388a5 next_plan
ccan/ccan/io/io.c:60
0x563dab238c83 do_plan
ccan/ccan/io/io.c:422
0x563dab238d3c io_ready
ccan/ccan/io/io.c:439
0x563dab239e5b io_loop
ccan/ccan/io/poll.c:470
0x563dab194399 io_loop_with_timers
lightningd/io_loop_with_timers.c:22
0x563dab199c29 main
lightningd/lightningd.c:1480
0x7f0cf0c80ca7 __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7f0cf0c80d64 __libc_start_main_impl
../csu/libc-start.c:360
0x563dab169020 ???
_start+0x20:0
0xffffffffffffffff ???
???:0
```
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
What changed, and why it matters
This commit adds a test that reveals Core Lightning can crash when a plugin produces an extremely long log message. The crash happens because the logging code sometimes allocates memory using one method but tries to free it with another, leading to an invalid-pointer error and an abort. The commit only adds the failing test; it does not include the actual fix, so the vulnerability remains unpatched in this commit.
Treat this as a denial-of-service issue: any plugin (including a malicious or compromised plugin) can crash the lightningd daemon by emitting a very long log line. The fix should ensure the logging path consistently uses the correct allocator for the active buffer, or always copies/truncates long lines through a single allocation path. Review commit 4d8f923a9a1468b8987dbb48e8fc988747f8c62f to identify the regression and apply a patch before this test is merged without xfail.
Security signals we found
Heap allocator mismatch (libc free on tal-allocated pointer)
Denial-of-service crash (SIGABRT) from plugin-generated log input
Use of xfail test to document a reproducible crash
Crash path crosses plugin JSON-RPC boundary
Evidence from the diff
The new test test_long_logs creates an inline plugin that emits a 300,000-character log line via plugin.log. The commit message explains that logv in lightningd/log.c uses vasprintf for normal log lines and frees the result with free, but for very long lines it switches to tal_fmt, which returns a tal-allocated pointer. Calling libc free on a tal pointer causes heap corruption (free(): invalid pointer) and SIGABRT. The test is marked xfail(strict=True), meaning it documents the bug and is expected to fail until a fix lands. The stack trace in the commit message confirms the crash path: plugin_read_json -> plugin_notification_handle -> plugin_log_handle -> log_ -> logv -> __GI___libc_free.
Changed components
lightningd/log.clightningd/plugin.cplugin logging interfaceInspect captured patch +17 / −0
diff --git a/tests/test_misc.py b/tests/test_misc.py
index ff30642d..b5f07c67 100644
--- a/tests/test_misc.py
+++ b/tests/test_misc.py
@@ -5405,3 +5405,20 @@ def test_tracing_socket(node_factory):
for key in ("id", "name", "timestamp", "duration", "traceId"):
assert key in span, f"Missing key {key} in span {span}"
assert span["localEndpoint"] == {"serviceName": "lightningd"}
+
+
+@pytest.mark.xfail(strict=True)
+def test_long_logs(node_factory):
+ """A plugin that creates a very long log entry. Lightningd should truncate
+ the output and not crash."""
+
+ def setup(plugin):
+ @plugin.method("produce-log")
+ def prod_log(plugin):
+ """Produce a silly and very long log message."""
+ plugin.log("X" * 300000)
+ return {}
+
+ l1 = node_factory.get_node(inline_plugin=setup)
+ l1.rpc.call("produce-log")
+
Why this scored 62/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.