linux-kernel - 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)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <eb8d0d62-f8a3-4198-b230-94f72028ac4e@suse.com>
Date: Wed, 31 Dec 2025 15:39:11 +1030
From: Qu Wenruo <wqu@...e.com>
To: Daniel J Blueman <daniel@...ra.org>
Cc: David Sterba <dsterba@...e.com>, Chris Mason <clm@...com>,
 Linux BTRFS <linux-btrfs@...r.kernel.org>, linux-crypto@...r.kernel.org,
 Linux Kernel <linux-kernel@...r.kernel.org>, kasan-dev@...glegroups.com,
 ryabinin.a.a@...il.com
Subject: 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)



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