Skip to content

lightningd: don't free the --conf filename when setconfig can't write it - #9711

Open
nepet wants to merge 1 commit into
ElementsProject:masterfrom
nepet:setconfig-conf-uaf
Open

nepet wants to merge 1 commit into
ElementsProject:masterfrom
nepet:setconfig-conf-uaf

Conversation

@nepet

@nepet nepet commented Nov 7, 2026

Copy link
Copy Markdown
Member

Checklist

Before submitting the PR, ensure the following tasks are completed. If an item is not applicable to your PR, please mark it as checked:

  • The changelog has been updated in the relevant commit(s) according to the guidelines.
  • Tests have been added or modified to reflect the changes.
  • Documentation has been reviewed and updated as needed.
  • Related issues have been listed and linked, including any that this PR closes.
  • Important All PRs must consider how to reverse any persistent changes for tools/lightning-downgrade

Fixes #9351.

With an explicit --conf in a directory lightningd can't write, the first setconfig fails with "Cannot write to config file", as it should. But config_not_writable() hands the file name to the command with tal_steal(), and with --conf that name is ld->config_filename itself, so freeing the failed command frees it. The next setconfig reads the freed name, passes the writability check against the wrong directory, and lightningd aborts in append_to_file().

This returns a copy instead, like the other branch of config_not_writable() already does. Introduced in 5e79cd4.

The test starts a node with --conf in a read-only directory and calls setconfig twice: both calls must fail with "Cannot write to config file", and the node must still be running.

This doesn't conflict with #9356, which makes the persistence path return errors instead of calling fatal(). That PR doesn't fix this bug on its own: with it, the second call still reads freed memory.

With an explicit --conf in a directory lightningd can't write, setconfig
fails with "Cannot write to config file", as it should. But
config_not_writable() hands the filename to the command with tal_steal(),
and with --conf that filename is ld->config_filename itself, so freeing
the failed command frees it.

The next setconfig then reads the freed name, passes the writability
check against the wrong directory, and lightningd aborts in
append_to_file() ("Could not write to config : No such file or
directory").

Return a copy instead, as the other branch of config_not_writable()
already does.

Introduced in 5e79cd4 ("lightningd: check for writability before
allowing setconfig.").

Fixes: ElementsProject#9351
Changelog-Fixed: lightningd: a `setconfig` after one that failed to write an explicit `--conf` file no longer crashes the node.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

setconfig aborts lightningd (FATAL SIGNAL 6) when it cannot persist the change: "Could not write to config : No such file or directory"

1 participant