linux-kernel - Re: [PATCH 4.19 29/71] btrfs: tree-checker: Verify inode item

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:   Wed, 11 Nov 2020 22:04:45 +0800
From:   Qu Wenruo <wqu@...e.com>
To:     Pavel Machek <pavel@....cz>
CC:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Nikolay Borisov <nborisov@...e.com>,
        Johannes Thumshirn <jthumshirn@...e.de>,
        David Sterba <dsterba@...e.com>,
        Ben Hutchings <ben.hutchings@...ethink.co.uk>
Subject: Re: [PATCH 4.19 29/71] btrfs: tree-checker: Verify inode item



On 2020/11/11 下午9:38, Pavel Machek wrote:
> Hi!
> 
>>>> From: Qu Wenruo <wqu@...e.com>
>>>>
>>>> commit 496245cac57e26d8b738d85c7a29cf9a47610f3f upstream.
>>>>
>>>> There is a report in kernel bugzilla about mismatch file type in dir
>>>> item and inode item.
>>>>
>>>> This inspires us to check inode mode in inode item.
>>>>
>>>> This patch will check the following members:
>>>
>>>> +	/* Here we use super block generation + 1 to handle log tree */
>>>> +	if (btrfs_inode_generation(leaf, iitem) > super_gen + 1) {
>>>> +		inode_item_err(fs_info, leaf, slot,
>>>> +			"invalid inode generation: has %llu expect (0, %llu]",
>>>> +			       btrfs_inode_generation(leaf, iitem),
>>>> +			       super_gen + 1);
>>>> +		return -EUCLEAN;
>>>> +	}
>>>
>>> Printk suggests btrfs_inode_generation() may not be zero, but the
>>> condition does not actually check that. Should that be added?
>>
>> Sorry, btrfs_inode_generation() here is exactly what we're checking
>> here, so what's wrong?
> 
> Quoted message says "(0, ...]", while message below says "[0, ...]". I
> assume that means that btrfs_inode_generation() may not be zero in the
> first case, but may be zero in the second case. But the code does not
> test for zero here.

Zero for inode generation is more or less in the grey zone.

For inodes which can be accessed by users, inode 0 may cause small
problems for send, but despite that, no obvious problem.

For btrfs internal generations, it can be 0 and cause nothing wrong.

So here we don't check inode_generation == 0 case at all, or we could
lead to too many false alerts for older btrfs.

Thanks,
Q

> 
> Best regards,
> 								Pavel
> 
>>>> +	/* Note for ROOT_TREE_DIR_ITEM, mkfs could set its transid 0 */
>>>> +	if (btrfs_inode_transid(leaf, iitem) > super_gen + 1) {
>>>> +		inode_item_err(fs_info, leaf, slot,
>>>> +			"invalid inode generation: has %llu expect [0, %llu]",
>>>> +			       btrfs_inode_transid(leaf, iitem), super_gen + 1);
>>>> +		return -EUCLEAN;
>>>> +	}
>