Re: [Linux Kernel Bug] kernel BUG in btrfs_get_root_ref (assertion failed: !anon_dev) and general protection fault in btrfs_update_reloc_root

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

On 2024/1/20 14:45, Chenyuan Yang wrote:
> Dear Linux Kernel Developers for BTRFS,
>
> We encountered "kernel BUG in btrfs_get_root_ref" and "general
> protection fault in btrfs_update_reloc_root" when testing BTRFS with
> Syzkaller and our generated specifications.
>
> For "kernel BUG in btrfs_get_root_ref", it is an internal assertion
> failure `ASSERT(!anon_dev)` in `btrfs_get_root_ref`
> (https://elixir.bootlin.com/linux/latest/source/fs/btrfs/disk-io.c#L1319),
> which asserts the `anno_dev` should be NULL but it is preallocated
> here. I've attached the reproducible C program and report.

Thanks for this report, unfortunately the C reproducer did nothing
related to btrfs, it doesn't even try to mount any btrfs (no dmesg on
mounting/unmounting a btrfs at all).

I guess I'm missing something?

And through the dmesg, it looks like there is something weird here.

Firstly the ASSERT() got triggered means we didn't get any anon_dev
number assigned, but create_subvol() would return an error if its
get_anon_bdev() call failed.

So the only explanation I can come up with is, in a special system that
there is no anon_dev allocated at all, get_anon_bdev() can get @anon_dev
assigned to 0.

In that case, it just means the ASSERT() is not correct as it doesn't
take this case into consideration at all.

I can definitely submit a patch to remove the ASSERT().

Do you have any dedicated URL for this btrfs_get_root_ref() failure that
you want to put as "Reported-by" tag? Or I should just use your gmail
address as "Reported-by"?

Thanks,
Qu

>
> For "general protection fault in btrfs_update_reloc_root", it attempts
> to deference the null pointer in `refcount_inc_not_zero(&root->refs)`
> (https://elixir.bootlin.com/linux/latest/source/fs/btrfs/disk-io.h#L101),
> which is invoked by `btrfs_update_reloc_root`
> (https://elixir.bootlin.com/linux/v6.7/source/fs/btrfs/relocation.c#L926).
> Here is the call trace:
> ```
> general protection fault, probably for non-canonical address
> 0xdffffc00000000cd: 0000 [#1] PREEMPT SMP KASAN
> KASAN: null-ptr-deref in range [0x0000000000000668-0x000000000000066f]
> [ 1904.856783][T69219] Call Trace:
> [ 1904.857057][T69219]  <TASK>
> [1904.857312][T69219] ? show_regs (arch/x86/kernel/dumpstack.c:479)
> [1904.857693][T69219] ? die_addr (arch/x86/kernel/dumpstack.c:421
> arch/x86/kernel/dumpstack.c:460)
> [1904.858074][T69219] ? exc_general_protection
> (arch/x86/kernel/traps.c:700 arch/x86/kernel/traps.c:642)
> [1904.858515][T69219] ? asm_exc_general_protection
> (./arch/x86/include/asm/idtentry.h:564)
> [1904.858941][T69219] ? btrfs_update_reloc_root
> (./include/linux/refcount.h:162 ./include/linux/refcount.h:227
> ./include/linux/refcount.h:245 fs/btrfs/disk-io.h:101
> fs/btrfs/relocation.c:926)
> [1904.859402][T69219] ? btrfs_update_reloc_root (fs/btrfs/relocation.c:929)
> ```
> Unfortunately, we failed to find the reproducible program for
> "general protection fault in btrfs_update_reloc_root". I have attached
> the report and log for it.
>
> If you have any questions or require more information, please feel
> free to contact us.
>
> Best,
> Chenyuan