lightningd: use json_escape_unescape_len for log message strings received from plugins
What the developer wrote
Authored by Matt Whitlock
lightningd: use json_escape_unescape_len for log message strings received from plugins
[ Reduced to just neatening, as 23997b2e1d882b2e99c50d29d7399080052e6568 did
the unescape handling already -- RR ]
What changed, and why it matters
This commit is a small cleanup in Core Lightning's plugin handling. It changes how log messages received from plugins are unescaped, switching to a dedicated function that handles lengths directly. The commit message explicitly says this is just 'neatening' and that the actual unescape handling was already done in an earlier commit. There is no direct evidence in the diff or commit message that this fixes a security vulnerability.
No urgent action required. Treat as routine code maintenance. If reviewing for security, verify that json_escape_unescape_len correctly handles embedded null bytes and length boundaries, and confirm the earlier commit 23997b2e1d882b2e99c50d29d7399080052e6568 addressed any actual security concern.
Security signals we found
Code change touches untrusted input parsing (plugin log messages)
Use of length-aware unescape function may reduce risk of length mismanagement
Commit message downplays security relevance, calling it 'neatening'
No explicit security issue, CVE, or vulnerability described in commit materials
Evidence from the diff
The patch in lightningd/plugin.c replaces a two-step process (creating a json_escape struct via json_escape_string_() then calling json_escape_unescape()) with a single call to json_escape_unescape_len(). The commit message states the real unescape handling was already addressed in commit 23997b2e1d882b2e99c50d29d7399080052e6568, and this change is only ‘neatening’. The code path still only activates when a backslash is present in the plugin log message, and the same unescape logic is applied.
Changed components
lightningd/plugin.cplugin log message handlingJSON escape/unescape utilitiesInspect captured patch +3 / −4
diff --git a/lightningd/plugin.c b/lightningd/plugin.c
index 2032640d..e1588f24 100644
--- a/lightningd/plugin.c
+++ b/lightningd/plugin.c
@@ -516,10 +516,9 @@ static const char *plugin_log_handle(struct plugin *plugin,
/* Only bother unescaping and splitting if it has \ */
if (memchr(plugin->buffer + msgtok->start, '\\', msgtok->end - msgtok->start)) {
- const char *log_escaped = plugin->buffer + msgtok->start;
- const size_t log_escaped_len = msgtok->end - msgtok->start;
- struct json_escape *esc = json_escape_string_(tmpctx, log_escaped, log_escaped_len);
- const char *log_msg = json_escape_unescape(tmpctx, esc);
+ const char *log_msg = json_escape_unescape_len(tmpctx,
+ plugin->buffer + msgtok->start,
+ msgtok->end - msgtok->start);
char **lines;
/* Weird \ escapes aren't handled by json_escape_unescape. This is for you, clboss! */
Why this scored 22/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.