Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
References: <20220209184103.47635-1-sashal@kernel.org>
 <20220209184103.47635-16-sashal@kernel.org> <Yg92voqmS9jz/rI+@kroah.com>
User-agent: mu4e 1.7.0; emacs 27.2
From:   Su Yue <l@damenly.su>
To:     Greg KH <greg@kroah.com>
Cc:     Sasha Levin <sashal@kernel.org>, linux-kernel@vger.kernel.org,
        stable@vger.kernel.org, David Sterba <dsterba@suse.com>,
        clm@fb.com, josef@toxicpanda.com, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH AUTOSEL 5.10 16/27] btrfs: tree-checker: check item_size
 for dev_item
Date:   Fri, 18 Feb 2022 19:25:20 +0800
In-reply-to: <Yg92voqmS9jz/rI+@kroah.com>
Message-ID: <1r00qtxj.fsf@damenly.su>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Precedence: bulk


On Fri 18 Feb 2022 at 11:36, Greg KH <greg@kroah.com> wrote:

> On Wed, Feb 09, 2022 at 01:40:52PM -0500, Sasha Levin wrote:
>> From: Su Yue <l@damenly.su>
>>
>> [ Upstream commit ea1d1ca4025ac6c075709f549f9aa036b5b6597d ]
>>
>> Check item size before accessing the device item to avoid out 
>> of bound
>> access, similar to inode_item check.
>>
>> Signed-off-by: Su Yue <l@damenly.su>
>> Reviewed-by: David Sterba <dsterba@suse.com>
>> Signed-off-by: David Sterba <dsterba@suse.com>
>> Signed-off-by: Sasha Levin <sashal@kernel.org>
>> ---
>>  fs/btrfs/tree-checker.c | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/fs/btrfs/tree-checker.c b/fs/btrfs/tree-checker.c
>> index d4a3a56726aa8..4a5ee516845f7 100644
>> --- a/fs/btrfs/tree-checker.c
>> +++ b/fs/btrfs/tree-checker.c
>> @@ -947,6 +947,7 @@ static int check_dev_item(struct 
>> extent_buffer *leaf,
>>  			  struct btrfs_key *key, int slot)
>>  {
>>  	struct btrfs_dev_item *ditem;
>> +	const u32 item_size = btrfs_item_size(leaf, slot);
>>
>>  	if (key->objectid != BTRFS_DEV_ITEMS_OBJECTID) {
>>  		dev_item_err(leaf, slot,
>> @@ -954,6 +955,13 @@ static int check_dev_item(struct 
>> extent_buffer *leaf,
>>  			     key->objectid, 
>>  BTRFS_DEV_ITEMS_OBJECTID);
>>  		return -EUCLEAN;
>>  	}
>> +
>> +	if (unlikely(item_size != sizeof(*ditem))) {
>> +		dev_item_err(leaf, slot, "invalid item size: has 
>> %u expect %zu",
>> +			     item_size, sizeof(*ditem));
>> +		return -EUCLEAN;
>> +	}
>> +
>>  	ditem = btrfs_item_ptr(leaf, slot, struct btrfs_dev_item);
>>  	if (btrfs_device_id(leaf, ditem) != key->offset) {
>>  		dev_item_err(leaf, slot,
>> --
>> 2.34.1
>>
>
> This adds a build warning, showing that the backport is not 
> correct, so
> I'll go drop this :(
>
And the warning is
========================================================================
arch/x86/kernel/head_64.o: warning: objtool: .text+0x5: 
unreachable instruction
fs/btrfs/tree-checker.c: In function 
\342\200\230check_dev_item\342\200\231:
fs/btrfs/tree-checker.c:950:53: warning: passing argument 2 of 
\342\200\230btrfs_item_size\342\200\231 makes pointer from integer 
without a cast [-Wint-conversion]
  950 |         const u32 item_size = btrfs_item_size(leaf, slot);
      |                                                     ^~~~
      |                                                     |
      |                                                     int
In file included from fs/btrfs/tree-checker.c:21:
fs/btrfs/ctree.h:1474:48: note: expected \342\200\230const struct 
btrfs_item *\342\200\231 but argument is of type 
\342\200\230int\342\200\231
 1474 |                                    const type *s) 
 \
      |                                    ~~~~~~~~~~~~^
fs/btrfs/ctree.h:1833:1: note: in expansion of macro 
\342\200\230BTRFS_SETGET_FUNCS\342\200\231
 1833 | BTRFS_SETGET_FUNCS(item_size, struct btrfs_item, size, 
 32);
      | ^~~~~~~~~~~~~~~~~~
========================================================================

The upstream patchset[1] merged in 5.17-rc1, changed second 
parameter
of btrfs_item_size() from btrfs_item * to int directly.
So yes, the backport is wrong.

I'm not familiar with stable backport progress. Should I file a 
patch
using btrfs_item *? Or just drop it?

The patch is related to  0c982944af27d131d3b74242f3528169f66950ad 
but
I wonder why the 0c98294 is not selected automatically.

Thanks.

[1]: 
https://patchwork.kernel.org/project/linux-btrfs/cover/cover.1634842475.git.josef@toxicpanda.com/
--
Su
> thanks,
>
> greg k-h