From: Chenyuan Yang <chenyuan0y@gmail.com>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: linux-btrfs@vger.kernel.org, clm@fb.com, josef@toxicpanda.com,
dsterba@suse.com, linux-kernel@vger.kernel.org,
syzkaller@googlegroups.com, Zijie Zhao <zzjas98@gmail.com>
Subject: Re: [Linux Kernel Bug] kernel BUG in btrfs_get_root_ref (assertion failed: !anon_dev) and general protection fault in btrfs_update_reloc_root
Date: Sat, 20 Jan 2024 00:25:13 -0600 [thread overview]
Message-ID: <CALGdzupFNufTRjhbuiUVa09PY4OQM1jYbFjHDQMf4WGY4fiANQ@mail.gmail.com> (raw)
In-Reply-To: <fbe2009b-1ae8-4ebb-98e6-7ca9c2ef6584@gmx.com>
[-- Attachment #1: Type: text/plain, Size: 4171 bytes --]
Hi Qu,
Thanks very much for your prompt reply!
>> it doesn't even try to mount any btrfs (no dmesg on
>> mounting/unmounting a btrfs at all).
>> I guess I'm missing something?
I just attached the mounted `mount_0.gz` in the repro in this email.
In the `btrfs_get_root_ref-repro.prog`, it seems that the Syzkaller
program mounts the btrfs in the beginning.
Sorry that I am not familiar with the mounting of the btrfs system.
>> 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"?
Thank you for highlighting this. Kindly use my Gmail address for the
'Reported-by' tag.
Best,
Chenyuan
On Fri, Jan 19, 2024 at 11:59 PM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>
>
>
> 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
[-- Attachment #2: mount_0.gz --]
[-- Type: application/x-gzip, Size: 20729 bytes --]
prev parent reply other threads:[~2024-01-20 6:25 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-20 4:15 [Linux Kernel Bug] kernel BUG in btrfs_get_root_ref (assertion failed: !anon_dev) and general protection fault in btrfs_update_reloc_root Chenyuan Yang
2024-01-20 5:59 ` Qu Wenruo
2024-01-20 6:25 ` Chenyuan Yang [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALGdzupFNufTRjhbuiUVa09PY4OQM1jYbFjHDQMf4WGY4fiANQ@mail.gmail.com \
--to=chenyuan0y@gmail.com \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.com \
--cc=syzkaller@googlegroups.com \
--cc=zzjas98@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.