linux-kernel - Re: [PATCH] btrfs: Added null check to extent

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] [day] [month] [year] [list]

Message-ID: <a52ac518-27fc-4853-be01-fdb03e49e862@gmx.com>
Date: Thu, 5 Sep 2024 07:01:25 +0930
From: Qu Wenruo <quwenruo.btrfs@....com>
To: dsterba@...e.cz
Cc: Ghanshyam Agrawal <ghanshyam1898@...il.com>, clm@...com,
 josef@...icpanda.com, dsterba@...e.com, linux-btrfs@...r.kernel.org,
 linux-kernel@...r.kernel.org,
 syzbot+9c3e0cdfbfe351b0bc0e@...kaller.appspotmail.com
Subject: Re: [PATCH] btrfs: Added null check to extent_root variable



在 2024/9/5 03:16, David Sterba 写道:
> On Wed, Sep 04, 2024 at 03:21:34PM +0930, Qu Wenruo wrote:
>>
>>
>> 在 2024/9/4 12:07, Ghanshyam Agrawal 写道:
>>> Reported-by: syzbot+9c3e0cdfbfe351b0bc0e@...kaller.appspotmail.com
>>> Closes:https://syzkaller.appspot.com/bug?extid=9c3e0cdfbfe351b0bc0e
>>> Signed-off-by: Ghanshyam Agrawal <ghanshyam1898@...il.com>
>>> ---
>>>    fs/btrfs/ref-verify.c | 3 +++
>>>    1 file changed, 3 insertions(+)
>>>
>>> diff --git a/fs/btrfs/ref-verify.c b/fs/btrfs/ref-verify.c
>>> index 9522a8b79d22..4e98ddf5e8df 100644
>>> --- a/fs/btrfs/ref-verify.c
>>> +++ b/fs/btrfs/ref-verify.c
>>> @@ -1002,6 +1002,9 @@ int btrfs_build_ref_tree(struct btrfs_fs_info *fs_info)
>>>    		return -ENOMEM;
>>>
>>>    	extent_root = btrfs_extent_root(fs_info, 0);
>>> +	if (!extent_root)
>>> +		return -EIO;
>>> +
>>
>> Can you reproduce the original bug and are sure it's an NULL extent tree
>> causing the problem?
>>
>> At least a quick glance into the console output shows there is no
>> special handling like rescue=ibadroots to ignore extent root, nor any
>> obvious corruption in the extent tree.
>>
>> If extent root is really empty, we should error out way earlier.
>>
>> Mind to explain the crash with more details?
>
> In the stack trace it looks the ref-verify mount option is enabled, I
> don't think we've tested that in combination with the rescue options as
> ref-verify is a debugging tool, must be built in config (by default is
> not and is not on distro configs).
>

Indeed it is the rescue=ibadroots mount option.
And unlike the regular mount options which all show a message line, none
of the rescue mount options will output an error message.

Thus that's why we're ignoring the missing extent root in
btrfs_read_block_groups().

In that case, yes the fix is correct.

Just need a small description on the combination to trigger the bug:

- Corrupted extent tree root

- rescue=ibadroots mount option

- Built-in ref-verify

Thanks,
Qu

> We should fix the bug where it crashes when run in syzkaller so we can
> allow it to continue coverage but otherwise I wouldn't put too much
> effort into that. I.e. if we can do a simple fallback and exit gracefully
> and not try to continue ref-verify + missint extent (or other trees).
>