Re: Soft tag and inline kasan triggering NULL pointer dereference, but not for hard tag and outline mode (was Re: [6.19-rc3] xxhash invalid access during BTRFS mount)

[Qu Wenruo]

在 2025/12/31 15:30, Daniel J Blueman 写道:
> On Wed, 31 Dec 2025 at 12:55, Qu Wenruo <wqu@xxxxxxxx> wrote:
> > 在 2025/12/31 14:35, Qu Wenruo 写道:
> > > 在 2025/12/31 13:59, Daniel J Blueman 写道:
> > > > On Tue, 30 Dec 2025 at 17:28, Qu Wenruo <wqu@xxxxxxxx> wrote:
> > > > > 在 2025/12/30 19:26, Qu Wenruo 写道:
> > > > > > 在 2025/12/30 18:02, Daniel J Blueman 写道:
> > > > > > > When mounting a BTRFS filesystem on 6.19-rc3 on ARM64 using xxhash
> > > > > > > checksumming and KASAN, I see invalid access:
> > > > > >
> > > > > > Mind to share the page size? As aarch64 has 3 different supported pages
> > > > > > size (4K, 16K, 64K).
> > > > > >
> > > > > > I'll give it a try on that branch. Although on my rc1 based development
> > > > > > branch it looks OK so far.
> > > > >
> > > > > Tried both 4K and 64K page size with KASAN enabled, all on 6.19-rc3 tag,
> > > > > no reproduce on newly created fs with xxhash.
> > > > >
> > > > > My environment is aarch64 VM on Orion O6 board.
> > > > >
> > > > > The xxhash implementation is the same xxhash64-generic:
> > > > >
> > > > > [   17.035933] BTRFS: device fsid 260364b9-d059-410c-92de-56243c346d6d
> > > > > devid 1 transid 8 /dev/mapper/test-scratch1 (253:2) scanned by mount
> > > > > (629)
> > > > > [   17.038033] BTRFS info (device dm-2): first mount of filesystem
> > > > > 260364b9-d059-410c-92de-56243c346d6d
> > > > > [   17.038645] BTRFS info (device dm-2): using xxhash64
> > > > > (xxhash64-generic) checksum algorithm
> > > > > [   17.041303] BTRFS info (device dm-2): checking UUID tree
> > > > > [   17.041390] BTRFS info (device dm-2): turning on async discard
> > > > > [   17.041393] BTRFS info (device dm-2): enabling free space tree
> > > > > [   19.032109] BTRFS info (device dm-2): last unmount of filesystem
> > > > > 260364b9-d059-410c-92de-56243c346d6d
> > > > >
> > > > > So there maybe something else involved, either related to the fs or the
> > > > > hardware.
> > > >
> > > > Thanks for checking Wenruo!
> > > >
> > > > With KASAN_GENERIC or KASAN_HW_TAGS, I don't see "kasan:
> > > > KernelAddressSanitizer initialized", so please ensure you are using
> > > > KASAN_SW_TAGS, KASAN_OUTLINE and 4KB pages. Full config at
> > > > https://gist.github.com/dblueman/cb4113f2cf880520081cf3f7c8dae13f
> > >
> > > Thanks a lot for the detailed configs.
> > >
> > > Unfortunately with that KASAN_SW_TAGS and KASAN_INLINE, the kernel can
> > > no longer boot, will always crash at boot with the following call trace,
> > > thus not even able to reach btrfs:
> > >
> > > [    3.938722]
> > > ==================================================================
> > > [    3.938739] BUG: KASAN: invalid-access in
> > > bpf_patch_insn_data+0x178/0x3b0
> > [...]
> > > Considering this is only showing up in KASAN_SW_TAGS, not HW_TAGS or the
> > > default generic mode, I'm wondering if this is a bug in KASAN itself.
> > >
> > > Adding KASAN people to the thread, meanwhile I'll check more KASAN +
> > > hardware combinations including x86_64 (since it's still 4K page size).
> >
> > I tried the following combinations, with a simple workload of mounting a
> > btrfs with xxhash checksum.
> >
> > According to the original report, the KASAN is triggered as btrfs
> > metadata verification time, thus mount option/workload shouldn't cause
> > any different, as all metadata will use the same checksum algorithm.
> >
> > x86_64 + generic + inline:      PASS
> > x86_64 + generic + outline:     PASS
> [..]
> > arm64 + hard tag:               PASS
> > arm64 + generic + inline:       PASS
> > arm64 + generic + outline:      PASS
>
> Do you see "KernelAddressSanitizer initialized" with KASAN_GENERIC
> and/or KASAN_HW_TAGS?

Yes. For my current running one using generic and inline, it shows at 
boot time:

[    0.000000] cma: Reserved 64 MiB at 0x00000000fc000000
[    0.000000] crashkernel reserved: 0x00000000dc000000 - 
0x00000000fc000000 (512 MB)
[    0.000000] KernelAddressSanitizer initialized (generic) <<<
[    0.000000] psci: probing for conduit method from ACPI.
[    0.000000] psci: PSCIv1.3 detected in firmware.


> I didn't see it in either case, suggesting it isn't implemented or
> supported on my system.
>
> > arm64 + soft tag + inline:      KASAN error at boot
> > arm64 + soft tag + outline:     KASAN error at boot
>
> Please retry with CONFIG_BPF unset.

I will retry but I believe this (along with your reports about hardware 
tags/generic not reporting the error) has already proven the problem is 
inside KASAN itself.

Not to mention the checksum verification/calculation is very critical 
part of btrfs, although in v6.19 there is a change in the crypto 
interface, I still doubt about whether we have a out-of-boundary access 
not exposed in such hot path until now.

Thanks,
Qu

> Thanks,
>    Dan