linux-kernel - Re: [PATCH] btrfs: Prevent the use of invalid extent root

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: <ea0254d9-e285-4f4d-be87-07aed832ebcd@gmx.com>
Date: Thu, 2 Jan 2025 15:12:33 +1030
From: Qu Wenruo <quwenruo.btrfs@....com>
To: Lizhi Xu <lizhi.xu@...driver.com>,
 syzbot+339e9dbe3a2ca419b85d@...kaller.appspotmail.com
Cc: clm@...com, dsterba@...e.com, josef@...icpanda.com,
 linux-btrfs@...r.kernel.org, linux-kernel@...r.kernel.org,
 syzkaller-bugs@...glegroups.com
Subject: Re: [PATCH] btrfs: Prevent the use of invalid extent root



在 2025/1/2 14:35, Lizhi Xu 写道:
> syzbot reported a null-ptr-deref in find_first_extent_item. [1]
>
> The btrfs filesystem did not successfully initialize extent root to the
> global root tree when mounted, this is because extent buffer is not uptodate,
> which causes the failure to read the tree root, which in turn causes extent
> root to not be inserted into the global root tree.

Sorry I didn't notice your fix and sent out my version.

I'd prefer your patch to mention that, this is not the common case.
As a btrfs can not be mounted with corrupted extent root.

Such fs can only be mounted with rescue=all,ro mount option as a data
salvage method.

And you do not need to go through all the global root/extent buffer
uptodate things, just mention a corrupted extent tree root is more than
good enough.

>
> To prevent this issue, add extent root check before using it.
>
> [1]
> Unable to handle kernel paging request at virtual address dfff800000000041
> KASAN: null-ptr-deref in range [0x0000000000000208-0x000000000000020f]
> Mem abort info:
>    ESR = 0x0000000096000005
>    EC = 0x25: DABT (current EL), IL = 32 bits
>    SET = 0, FnV = 0
>    EA = 0, S1PTW = 0
>    FSC = 0x05: level 1 translation fault
> Data abort info:
>    ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
>    CM = 0, WnR = 0, TnD = 0, TagAccess = 0
>    GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> [dfff800000000041] address between user and kernel address ranges
> Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP
> Modules linked in:
> CPU: 1 UID: 0 PID: 6417 Comm: syz-executor153 Not tainted 6.13.0-rc3-syzkaller-g573067a5a685 #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
> pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> pc : find_first_extent_item+0xac/0x674 fs/btrfs/scrub.c:1375
> lr : find_first_extent_item+0xa4/0x674 fs/btrfs/scrub.c:1374
> sp : ffff8000a5be6e60
> x29: ffff8000a5be6f80 x28: dfff800000000000 x27: 0000000000000000
> x26: 0000000000400000 x25: 0000000000400000 x24: 1fffe0001848ab0a
> x23: 0000000000000208 x22: ffff8000a5be6f20 x21: ffff0000c2455858
> x20: ffff8000a5be6ec0 x19: ffff0000db072010 x18: ffff0000db072010
> x17: 000000000000e32c x16: ffff80008b5fea08 x15: 0000000000000004
> x14: 1fffe0001b60c031 x13: 0000000000000000 x12: ffff700014b7cdd8
> x11: ffff80008257f234 x10: 0000000000ff0100 x9 : 0000000000000000
> x8 : 0000000000000041 x7 : 0000000000000000 x6 : 000000000000003f
> x5 : 0000000000000040 x4 : 0000000000000008 x3 : 0000000000400000
> x2 : 0000000000100000 x1 : ffff0000db072010 x0 : 0000000000000000
> Call trace:
>   find_first_extent_item+0xac/0x674 fs/btrfs/scrub.c:1375 (P)
>   scrub_find_fill_first_stripe+0x2c0/0xab8 fs/btrfs/scrub.c:1551
>   queue_scrub_stripe fs/btrfs/scrub.c:1921 [inline]
>   scrub_simple_mirror+0x440/0x7e4 fs/btrfs/scrub.c:2152
>   scrub_stripe+0x7e4/0x2174 fs/btrfs/scrub.c:2317
>   scrub_chunk+0x268/0x41c fs/btrfs/scrub.c:2443
>   scrub_enumerate_chunks+0xd38/0x1784 fs/btrfs/scrub.c:2707
>   btrfs_scrub_dev+0x5a8/0xb34 fs/btrfs/scrub.c:3029
>   btrfs_ioctl_scrub+0x1f4/0x3e8 fs/btrfs/ioctl.c:3248
>   btrfs_ioctl+0x6a8/0xb04 fs/btrfs/ioctl.c:5246
>   vfs_ioctl fs/ioctl.c:51 [inline]
>   __do_sys_ioctl fs/ioctl.c:906 [inline]
>   __se_sys_ioctl fs/ioctl.c:892 [inline]
>   __arm64_sys_ioctl+0x14c/0x1cc fs/ioctl.c:892
>   __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
>
> Reported-by: syzbot+339e9dbe3a2ca419b85d@...kaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=339e9dbe3a2ca419b85d

If you understand the reason why this is possible in the first place,
you can find out the offending commit, where the rescue=ibadroot mount
option is introduced.

Although in the latest kernel it's b979547513ff ("btrfs: scrub:
introduce helper to find and fill sector info for a scrub_stripe")
causing the problem, the same problem also happens before the scrub rework.

So next time please add related fixes: tag for similar reports.

Thanks,
Qu

> Signed-off-by: Lizhi Xu <lizhi.xu@...driver.com>
> ---
>   fs/btrfs/scrub.c | 6 +++++-
>   1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
> index 204c928beaf9..6080839cec95 100644
> --- a/fs/btrfs/scrub.c
> +++ b/fs/btrfs/scrub.c
> @@ -1372,10 +1372,14 @@ static int find_first_extent_item(struct btrfs_root *extent_root,
>   				  struct btrfs_path *path,
>   				  u64 search_start, u64 search_len)
>   {
> -	struct btrfs_fs_info *fs_info = extent_root->fs_info;
> +	struct btrfs_fs_info *fs_info;
>   	struct btrfs_key key;
>   	int ret;
>
> +	if (!extent_root)
> +		return -ENOENT;
> +
> +	fs_info = extent_root->fs_info;
>   	/* Continue using the existing path */
>   	if (path->nodes[0])
>   		goto search_forward;