[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dfc3110a-0380-4511-b044-e440c2c3ce70@suse.com>
Date: Sat, 25 Oct 2025 20:52:06 +1030
From: Qu Wenruo <wqu@...e.com>
To: Shardul Bankar <shardulsb08@...il.com>, linux-btrfs@...r.kernel.org
Cc: clm@...com, dsterba@...e.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH fs/btrfs] btrfs: fix memory leak of qgroup_list in
btrfs_add_qgroup_relation
在 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@...il.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) {
>
>
Powered by blists - more mailing lists