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: <293c10e8-fa6b-4da2-8d7d-9eaf6b4ecd4b@suse.com>
Date: Sat, 25 Oct 2025 20:36:56 +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 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)
> 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