Re: [PATCH v4 1/2] debugfs: fix use-after-free in debugfs_read_file_str()
From: Greg KH
Date: Sun Sep 27 2026 - 12:37:51 EST
On Sat, Sep 26, 2026 at 04:58:43PM -0300, Aldo Ariel Panzardo wrote:
> debugfs_write_file_str() publishes a new string pointer via
> rcu_assign_pointer(), waits for a grace period with synchronize_rcu(),
> then frees the old string.
>
> debugfs_read_file_str() dereferences file->private_data without holding
> an RCU read-side critical section: it loads the pointer, calls strlen()
> on it, and then copies the string. If a concurrent writer completes
> synchronize_rcu() and kfree()s the old string between the load and the
> use, the reader accesses freed memory.
>
> Fix by measuring the string length under rcu_read_lock(), allocating
> with GFP_KERNEL outside the critical section, and then copying with
> strscpy() under a second rcu_read_lock(). If the current string no
> longer fits the allocated buffer, retry with a PAGE_SIZE allocation
> which is the upper bound enforced by the write path.
Please don't use a LLM to write a changelog text without crediting it :(
>
> Cc: stable@xxxxxxxxxxxxxxx
> Assisted-by: sashiko.dev <sashiko-bot@xxxxxxxxxx>
> Signed-off-by: Aldo Ariel Panzardo <qwe.aldo@xxxxxxxxx>
> ---
> fs/debugfs/file.c | 39 +++++++++++++++++++++++++--------------
> 1 file changed, 25 insertions(+), 14 deletions(-)
>
> diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
> index 08de6652a..f9a1f7739 100644
> --- a/fs/debugfs/file.c
> +++ b/fs/debugfs/file.c
> @@ -1018,7 +1018,7 @@ ssize_t debugfs_read_file_str(struct file *file, char __user *user_buf,
> size_t count, loff_t *ppos)
> {
> struct dentry *dentry = F_DENTRY(file);
> - char *str, *copy = NULL;
> + char *str, *copy;
> int copy_len, len;
> ssize_t ret;
>
> @@ -1026,26 +1026,37 @@ ssize_t debugfs_read_file_str(struct file *file, char __user *user_buf,
> if (unlikely(ret))
> return ret;
>
> - str = *(char **)file->private_data;
> - len = strlen(str) + 1;
> - copy = kmalloc(len, GFP_KERNEL);
> - if (!copy) {
> - debugfs_file_put(dentry);
> - return -ENOMEM;
> - }
> + len = 0;
> + for (;;) {
This is probably not right, don't do loops like this. Either fail or
succeed, don't loop.
Again, let's see the real use case here, what is hitting this in
userspace today and what debugfs kernel files are causing it?
thanks,
greg k-h