lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ