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:39, Qu Wenruo 写道:
> 在 2025/12/31 15:30, Daniel J Blueman 写道:
> > On Wed, 31 Dec 2025 at 12:55, Qu Wenruo <wqu@xxxxxxxx> wrote:
[...]
> > > 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.

BTW, I tried to bisect the cause, and indeed got the same KASAN warning 
during some runs just mounting a newly created btrfs, and the csum 
algorithm doesn't seem to matter.
Both xxhash and sha256 can trigger it randomly.

Unfortunately there is no reliable way to reproduce the kasan warning, I 
have to cancel the bisection.

For now I strongly doubt if this is a bug in software tag-based KASAN 
itself, and that's the only combination resulting the warning.

If KASAN people has some clue I'm very happy to test, meanwhile I'll 
keep using hardware tag-based kasan on arm64 and generic one on x86_64 
to test btrfs, to make sure no obvious bad memory access.

Thanks,
Qu

> Thanks,
> Qu
>
> > Thanks,
> >    Dan