Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: Shardul Bankar <shardulsb08@gmail.com>, linux-btrfs@vger.kernel.org
Cc: clm@fb.com, dsterba@suse.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH fs/btrfs] btrfs: fix memory leak of qgroup_list in btrfs_add_qgroup_relation
Date: Sat, 25 Oct 2025 20:52:06 +1030	[thread overview]
Message-ID: <dfc3110a-0380-4511-b044-e440c2c3ce70@suse.com> (raw)
In-Reply-To: <293c10e8-fa6b-4da2-8d7d-9eaf6b4ecd4b@suse.com>



在 2025/10/25 20:36, Qu Wenruo 写道:
> 
> 
> 在 2025/10/25 19:59, Shardul Bankar 写道:
>> When btrfs_add_qgroup_relation() is called with invalid qgroup levels
>> (src >= dst), the function returns -EINVAL directly without freeing the
>> preallocated qgroup_list structure passed by the caller. This causes a
>> memory leak because the caller unconditionally sets the pointer to NULL
>> after the call, preventing any cleanup.
>>
>> The issue occurs because the level validation check happens before the
>> mutex is acquired and before any error handling path that would free
>> the prealloc pointer. On this early return, the cleanup code at the
>> 'out' label (which includes kfree(prealloc)) is never reached.
>>
>> In btrfs_ioctl_qgroup_assign(), the code pattern is:
>>
>>      prealloc = kzalloc(sizeof(*prealloc), GFP_KERNEL);
>>      ret = btrfs_add_qgroup_relation(trans, sa->src, sa->dst, prealloc);
>>      prealloc = NULL;  // Always set to NULL regardless of return value
>>      ...
>>      kfree(prealloc);  // This becomes kfree(NULL), does nothing
>>
>> When the level check fails, 'prealloc' is never freed by either the
>> callee or the caller, resulting in a 64-byte memory leak per failed
>> operation. This can be triggered repeatedly by an unprivileged user
>> with access to a writable btrfs mount, potentially exhausting kernel
>> memory.
>>
>> Fix this by changing the early return to a goto that reaches the
>> cleanup code, ensuring prealloc is always freed on all error paths.
>>
>> Reported-by: BRF (btrfs runtime fuzzer)

And forgot to mention, if this is some tool that has sent a report to 
the mailing list, please add a "Link:" tag.

If it's only something internal to your organization/project, please 
remove this line, it makes no sense for upstream.

Thanks,
Qu

>> Fixes: 8465ecec9611 ("btrfs: Check qgroup level in kernel qgroup 
>> assign.")
>> Signed-off-by: Shardul Bankar <shardulsb08@gmail.com>
>> ---
>>   fs/btrfs/qgroup.c | 6 ++++--
>>   1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c
>> index 1175b8192cd7..0a25bfdd442f 100644
>> --- a/fs/btrfs/qgroup.c
>> +++ b/fs/btrfs/qgroup.c
>> @@ -1539,8 +1539,10 @@ int btrfs_add_qgroup_relation(struct 
>> btrfs_trans_handle *trans, u64 src, u64 dst
>>       ASSERT(prealloc);
>>       /* Check the level of src and dst first */
>> -    if (btrfs_qgroup_level(src) >= btrfs_qgroup_level(dst))
>> -        return -EINVAL;
>> +    if (btrfs_qgroup_level(src) >= btrfs_qgroup_level(dst)) {
>> +        ret = -EINVAL;
>> +        goto out;
>> +    }
> 
> Out will call mutex_unlock(), but we haven't yet even locked the mutex.
> 
> Please just call kfree(prealloc) then return.
> 
> Thanks,
> Qu
> 
>>       mutex_lock(&fs_info->qgroup_ioctl_lock);
>>       if (!fs_info->quota_root) {
> 
> 


  reply	other threads:[~2025-10-25 10:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-25  9:29 [PATCH fs/btrfs] btrfs: fix memory leak of qgroup_list in btrfs_add_qgroup_relation Shardul Bankar
2025-10-25 10:06 ` Qu Wenruo
2025-10-25 10:22   ` Qu Wenruo [this message]
2025-10-25 12:05 ` [PATCH v2 fs/btrfs v2] " Shardul Bankar
2025-10-25 19:36   ` Filipe Manana
2025-10-25 20:00 ` [PATCH v3 fs/btrfs v3] " Shardul Bankar
2025-10-27  5:42   ` Qu Wenruo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dfc3110a-0380-4511-b044-e440c2c3ce70@suse.com \
    --to=wqu@suse.com \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shardulsb08@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox