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]
Date:   Tue, 30 Mar 2021 17:15:10 -0400
From:   Sasha Levin <sashal@...nel.org>
To:     dsterba@...e.cz, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org, Qu Wenruo <wqu@...e.com>,
        David Sterba <dsterba@...e.com>, linux-btrfs@...r.kernel.org
Subject: Re: [PATCH AUTOSEL 5.11 26/44] btrfs: track qgroup released data in
 own variable in insert_prealloc_file_extent

On Thu, Mar 25, 2021 at 01:08:02PM +0100, David Sterba wrote:
>On Thu, Mar 25, 2021 at 07:24:41AM -0400, Sasha Levin wrote:
>> From: Qu Wenruo <wqu@...e.com>
>>
>> [ Upstream commit fbf48bb0b197e6894a04c714728c952af7153bf3 ]
>>
>> There is a piece of weird code in insert_prealloc_file_extent(), which
>> looks like:
>>
>> 	ret = btrfs_qgroup_release_data(inode, file_offset, len);
>> 	if (ret < 0)
>> 		return ERR_PTR(ret);
>> 	if (trans) {
>> 		ret = insert_reserved_file_extent(trans, inode,
>> 						  file_offset, &stack_fi,
>> 						  true, ret);
>> 	...
>> 	}
>> 	extent_info.is_new_extent = true;
>> 	extent_info.qgroup_reserved = ret;
>> 	...
>>
>> Note how the variable @ret is abused here, and if anyone is adding code
>> just after btrfs_qgroup_release_data() call, it's super easy to
>> overwrite the @ret and cause tons of qgroup related bugs.
>>
>> Fix such abuse by introducing new variable @qgroup_released, so that we
>> won't reuse the existing variable @ret.
>>
>> Signed-off-by: Qu Wenruo <wqu@...e.com>
>> Reviewed-by: David Sterba <dsterba@...e.com>
>> Signed-off-by: David Sterba <dsterba@...e.com>
>> Signed-off-by: Sasha Levin <sashal@...nel.org>
>
>This patch is a preparatory work and does not make sense for backport
>standalone. Either this one plus
>https://lore.kernel.org/linux-btrfs/20210303104152.105877-2-wqu@suse.com/
>or neither. And IIRC it does not apply directly and needs some
>additional review before it can be backported to older code base, so it
>has no CC: stable tags.

I'll drop it, thanks!

-- 
Thanks,
Sasha

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ