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 <wqu@suse.com>]

在 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@suse.com> 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
> 
>