[6.19-rc3] xxhash invalid access during BTRFS mount

[6.19-rc3] xxhash invalid access during BTRFS mount

[Daniel J Blueman]

Hi Dave, Chris et al,

When mounting a BTRFS filesystem on 6.19-rc3 on ARM64 using xxhash
checksumming and KASAN, I see invalid access:

BTRFS info (device nvme0n1p5): first mount of filesystem
f99f2753-0283-4f93-8f5d-7a9f59f148cc
BTRFS info (device nvme0n1p5): using xxhash64 (xxhash64-generic)
checksum algorithm
==================================================================
BUG: KASAN: invalid-access in xxh64_update (lib/xxhash.c:143 lib/xxhash.c:283)
Read of size 8 at addr 21ff000802247000 by task kworker/u48:3/48
Pointer tag: [21], memory tag: [c0]

CPU: 1 UID: 0 PID: 48 Comm: kworker/u48:3 Tainted: G      E
6.19.0-rc3 #19 PREEMPTLAZY
Tainted: [E]=UNSIGNED_MODULE
Hardware name: LENOVO 83ED/LNVNB161216, BIOS NHCN60WW 09/11/2025
Workqueue: btrfs-endio-meta simple_end_io_work
Call trace:
show_stack (arch/arm64/kernel/stacktrace.c:501) (C)
dump_stack_lvl (lib/dump_stack.c:122)
print_address_description.isra.0 (mm/kasan/report.c:379)
print_report (mm/kasan/report.c:450 (discriminator 1)
mm/kasan/report.c:483 (discriminator 1))
kasan_report (mm/kasan/report.c:597)
kasan_check_range (mm/kasan/sw_tags.c:86 (discriminator 1))
__hwasan_loadN_noabort (mm/kasan/sw_tags.c:158)
xxh64_update (lib/xxhash.c:143 lib/xxhash.c:283)
xxhash64_update (crypto/xxhash_generic.c:49)
crypto_shash_finup (crypto/shash.c:123 (discriminator 1))
csum_tree_block (fs/btrfs/disk-io.c:110 (discriminator 3))
btrfs_validate_extent_buffer (fs/btrfs/disk-io.c:404)
end_bbio_meta_read (fs/btrfs/extent_io.c:3822 (discriminator 1))
btrfs_bio_end_io (fs/btrfs/bio.c:146)
simple_end_io_work (fs/btrfs/bio.c:382)
process_one_work (./arch/arm64/include/asm/jump_label.h:36
./include/trace/events/workqueue.h:110 kernel/workqueue.c:3262)
worker_thread (kernel/workqueue.c:3334 (discriminator 2)
kernel/workqueue.c:3421 (discriminator 2))
kthread (kernel/kthread.c:463)
ret_from_fork (arch/arm64/kernel/entry.S:861)

The buggy address belongs to the physical page:
page: refcount:2 mapcount:0 mapping:00000000973bd0ac index:0x9731 pfn:0x882247
memcg:aaff000800ae1b00
aops:btree_aops ino:1
flags: 0x47e400000004020(lru|private|node=0|zone=2|kasantag=0x3f)
raw: 047e400000004020 fffffdffe0089188 fffffdffe0089208 ccff000814148300
raw: 0000000000009731 10ff0008493322d0 00000002ffffffff aaff000800ae1b00
page dumped because: kasan: bad access detected

Memory state around the buggy address:
ffff000802246e00: 21 21 21 21 21 21 21 21 21 21 21 21 21 21 21 21
ffff000802246f00: 21 21 21 21 21 21 21 21 21 21 21 21 21 21 21 21
>ffff000802247000: c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0
^
ffff000802247100: c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0
ffff000802247200: c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0

Let me know for any further testing or debug.

Thanks,
  Dan
--
Daniel J Blueman

Re: [6.19-rc3] xxhash invalid access during BTRFS mount

[Qu Wenruo]

在 2025/12/30 18:02, Daniel J Blueman 写道:
> Hi Dave, Chris et al,
> 
> 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.


And is this KASAN triggered for this particular fs or all any btrfs (no 
matter csum)?

Thanks,
Qu

> 
> BTRFS info (device nvme0n1p5): first mount of filesystem
> f99f2753-0283-4f93-8f5d-7a9f59f148cc
> BTRFS info (device nvme0n1p5): using xxhash64 (xxhash64-generic)
> checksum algorithm
> ==================================================================
> BUG: KASAN: invalid-access in xxh64_update (lib/xxhash.c:143 lib/xxhash.c:283)
> Read of size 8 at addr 21ff000802247000 by task kworker/u48:3/48
> Pointer tag: [21], memory tag: [c0]
> 
> CPU: 1 UID: 0 PID: 48 Comm: kworker/u48:3 Tainted: G      E
> 6.19.0-rc3 #19 PREEMPTLAZY
> Tainted: [E]=UNSIGNED_MODULE
> Hardware name: LENOVO 83ED/LNVNB161216, BIOS NHCN60WW 09/11/2025
> Workqueue: btrfs-endio-meta simple_end_io_work
> Call trace:
> show_stack (arch/arm64/kernel/stacktrace.c:501) (C)
> dump_stack_lvl (lib/dump_stack.c:122)
> print_address_description.isra.0 (mm/kasan/report.c:379)
> print_report (mm/kasan/report.c:450 (discriminator 1)
> mm/kasan/report.c:483 (discriminator 1))
> kasan_report (mm/kasan/report.c:597)
> kasan_check_range (mm/kasan/sw_tags.c:86 (discriminator 1))
> __hwasan_loadN_noabort (mm/kasan/sw_tags.c:158)
> xxh64_update (lib/xxhash.c:143 lib/xxhash.c:283)
> xxhash64_update (crypto/xxhash_generic.c:49)
> crypto_shash_finup (crypto/shash.c:123 (discriminator 1))
> csum_tree_block (fs/btrfs/disk-io.c:110 (discriminator 3))
> btrfs_validate_extent_buffer (fs/btrfs/disk-io.c:404)
> end_bbio_meta_read (fs/btrfs/extent_io.c:3822 (discriminator 1))
> btrfs_bio_end_io (fs/btrfs/bio.c:146)
> simple_end_io_work (fs/btrfs/bio.c:382)
> process_one_work (./arch/arm64/include/asm/jump_label.h:36
> ./include/trace/events/workqueue.h:110 kernel/workqueue.c:3262)
> worker_thread (kernel/workqueue.c:3334 (discriminator 2)
> kernel/workqueue.c:3421 (discriminator 2))
> kthread (kernel/kthread.c:463)
> ret_from_fork (arch/arm64/kernel/entry.S:861)
> 
> The buggy address belongs to the physical page:
> page: refcount:2 mapcount:0 mapping:00000000973bd0ac index:0x9731 pfn:0x882247
> memcg:aaff000800ae1b00
> aops:btree_aops ino:1
> flags: 0x47e400000004020(lru|private|node=0|zone=2|kasantag=0x3f)
> raw: 047e400000004020 fffffdffe0089188 fffffdffe0089208 ccff000814148300
> raw: 0000000000009731 10ff0008493322d0 00000002ffffffff aaff000800ae1b00
> page dumped because: kasan: bad access detected
> 
> Memory state around the buggy address:
> ffff000802246e00: 21 21 21 21 21 21 21 21 21 21 21 21 21 21 21 21
> ffff000802246f00: 21 21 21 21 21 21 21 21 21 21 21 21 21 21 21 21
>> ffff000802247000: c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0
> ^
> ffff000802247100: c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0
> ffff000802247200: c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0
> 
> Let me know for any further testing or debug.
> 
> Thanks,
>    Dan
> --
> Daniel J Blueman
> 

Re: [6.19-rc3] xxhash invalid access during BTRFS mount

[Qu Wenruo]

在 2025/12/30 19:26, Qu Wenruo 写道:
> 
> 
> 在 2025/12/30 18:02, Daniel J Blueman 写道:
>> Hi Dave, Chris et al,
>>
>> 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,
Qu

> 
> 
> And is this KASAN triggered for this particular fs or all any btrfs (no 
> matter csum)?
> 
> Thanks,
> Qu
> 
>>
>> BTRFS info (device nvme0n1p5): first mount of filesystem
>> f99f2753-0283-4f93-8f5d-7a9f59f148cc
>> BTRFS info (device nvme0n1p5): using xxhash64 (xxhash64-generic)
>> checksum algorithm
>> ==================================================================
>> BUG: KASAN: invalid-access in xxh64_update (lib/xxhash.c:143 lib/ 
>> xxhash.c:283)
>> Read of size 8 at addr 21ff000802247000 by task kworker/u48:3/48
>> Pointer tag: [21], memory tag: [c0]
>>
>> CPU: 1 UID: 0 PID: 48 Comm: kworker/u48:3 Tainted: G      E
>> 6.19.0-rc3 #19 PREEMPTLAZY
>> Tainted: [E]=UNSIGNED_MODULE
>> Hardware name: LENOVO 83ED/LNVNB161216, BIOS NHCN60WW 09/11/2025
>> Workqueue: btrfs-endio-meta simple_end_io_work
>> Call trace:
>> show_stack (arch/arm64/kernel/stacktrace.c:501) (C)
>> dump_stack_lvl (lib/dump_stack.c:122)
>> print_address_description.isra.0 (mm/kasan/report.c:379)
>> print_report (mm/kasan/report.c:450 (discriminator 1)
>> mm/kasan/report.c:483 (discriminator 1))
>> kasan_report (mm/kasan/report.c:597)
>> kasan_check_range (mm/kasan/sw_tags.c:86 (discriminator 1))
>> __hwasan_loadN_noabort (mm/kasan/sw_tags.c:158)
>> xxh64_update (lib/xxhash.c:143 lib/xxhash.c:283)
>> xxhash64_update (crypto/xxhash_generic.c:49)
>> crypto_shash_finup (crypto/shash.c:123 (discriminator 1))
>> csum_tree_block (fs/btrfs/disk-io.c:110 (discriminator 3))
>> btrfs_validate_extent_buffer (fs/btrfs/disk-io.c:404)
>> end_bbio_meta_read (fs/btrfs/extent_io.c:3822 (discriminator 1))
>> btrfs_bio_end_io (fs/btrfs/bio.c:146)
>> simple_end_io_work (fs/btrfs/bio.c:382)
>> process_one_work (./arch/arm64/include/asm/jump_label.h:36
>> ./include/trace/events/workqueue.h:110 kernel/workqueue.c:3262)
>> worker_thread (kernel/workqueue.c:3334 (discriminator 2)
>> kernel/workqueue.c:3421 (discriminator 2))
>> kthread (kernel/kthread.c:463)
>> ret_from_fork (arch/arm64/kernel/entry.S:861)
>>
>> The buggy address belongs to the physical page:
>> page: refcount:2 mapcount:0 mapping:00000000973bd0ac index:0x9731 
>> pfn:0x882247
>> memcg:aaff000800ae1b00
>> aops:btree_aops ino:1
>> flags: 0x47e400000004020(lru|private|node=0|zone=2|kasantag=0x3f)
>> raw: 047e400000004020 fffffdffe0089188 fffffdffe0089208 ccff000814148300
>> raw: 0000000000009731 10ff0008493322d0 00000002ffffffff aaff000800ae1b00
>> page dumped because: kasan: bad access detected
>>
>> Memory state around the buggy address:
>> ffff000802246e00: 21 21 21 21 21 21 21 21 21 21 21 21 21 21 21 21
>> ffff000802246f00: 21 21 21 21 21 21 21 21 21 21 21 21 21 21 21 21
>>> ffff000802247000: c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0
>> ^
>> ffff000802247100: c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0
>> ffff000802247200: c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0
>>
>> Let me know for any further testing or debug.
>>
>> Thanks,
>>    Dan
>> -- 
>> Daniel J Blueman
>>
> 
> 

Re: [6.19-rc3] xxhash invalid access during BTRFS mount

[Daniel J Blueman]

On Tue, 30 Dec 2025 at 17:28, Qu Wenruo <wqu@suse.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

Also ensure your mount options resolve similar to
"rw,relatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvolid=5,subvol=/".

Failing that, let me know of any significant filesystem differences from:
# btrfs inspect-internal dump-super /dev/nvme0n1p5
superblock: bytenr=65536, device=/dev/nvme0n1p5
---------------------------------------------------------
csum_type        1 (xxhash64)
csum_size        8
csum            0x97ec1a3695ae35d0 [match]
bytenr            65536
flags            0x1
            ( WRITTEN )
magic            _BHRfS_M [match]
fsid            f99f2753-0283-4f93-8f5d-7a9f59f148cc
metadata_uuid        00000000-0000-0000-0000-000000000000
label
generation        34305
root            586579968
sys_array_size        129
chunk_root_generation    33351
root_level        0
chunk_root        19357892608
chunk_root_level    0
log_root        0
log_root_transid (deprecated)    0
log_root_level        0
total_bytes        83886080000
bytes_used        14462930944
sectorsize        4096
nodesize        16384
leafsize (deprecated)    16384
stripesize        4096
root_dir        6
num_devices        1
compat_flags        0x0
compat_ro_flags        0x3
            ( FREE_SPACE_TREE |
              FREE_SPACE_TREE_VALID )
incompat_flags        0x361
            ( MIXED_BACKREF |
              BIG_METADATA |
              EXTENDED_IREF |
              SKINNY_METADATA |
              NO_HOLES )
cache_generation    0
uuid_tree_generation    34305
dev_item.uuid        86166b5f-2258-4ab9-aac6-0d0e37ffbdb6
dev_item.fsid        f99f2753-0283-4f93-8f5d-7a9f59f148cc [match]
dev_item.type        0
dev_item.total_bytes    83886080000
dev_item.bytes_used    22624075776
dev_item.io_align    4096
dev_item.io_width    4096
dev_item.sector_size    4096
dev_item.devid        1
dev_item.dev_group    0
dev_item.seek_speed    0
dev_item.bandwidth    0
dev_item.generation    0

Thanks,
  Dan
--
Daniel J Blueman

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 13:59, Daniel J Blueman 写道:
> On Tue, 30 Dec 2025 at 17:28, Qu Wenruo <wqu@suse.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
[    3.938766] Write of size 6720 at addr 96ff80008024b120 by task systemd/1
[    3.938772] Pointer tag: [96], memory tag: [08]
[    3.938775]
[    3.938791] CPU: 5 UID: 0 PID: 1 Comm: systemd Not tainted 
6.19.0-rc3-custom #159 PREEMPT(voluntary)
[    3.938801] Hardware name: QEMU KVM Virtual Machine, BIOS unknown 
2/2/2022
[    3.938805] Call trace:
[    3.938808]  show_stack+0x20/0x38 (C)
[    3.938827]  dump_stack_lvl+0x60/0x80
[    3.938846]  print_report+0x17c/0x488
[    3.938860]  kasan_report+0xbc/0x108
[    3.938887]  kasan_check_range+0x7c/0xa0
[    3.938895]  __asan_memmove+0x54/0x98
[    3.938904]  bpf_patch_insn_data+0x178/0x3b0
[    3.938912]  bpf_check+0x2720/0x49d8
[    3.938920]  bpf_prog_load+0xbd0/0x13e8
[    3.938928]  __sys_bpf+0xba0/0x2dc8
[    3.938935]  __arm64_sys_bpf+0x50/0x70
[    3.938943]  invoke_syscall.constprop.0+0x88/0x148
[    3.938957]  el0_svc_common.constprop.0+0x7c/0x148
[    3.938964]  do_el0_svc+0x38/0x50
[    3.938970]  el0_svc+0x3c/0x198
[    3.938984]  el0t_64_sync_handler+0xa0/0xe8
[    3.938993]  el0t_64_sync+0x198/0x1a0
[    3.939001]
[    3.939003] The buggy address belongs to a 2-page vmalloc region 
starting at 0x96ff80008024b000 allocated at bpf_check+0x158/0x49d8
[    3.939015] The buggy address belongs to the physical page:
[    3.939026] page: refcount:1 mapcount:0 mapping:0000000000000000 
index:0x0 pfn:0x10cede
[    3.939035] flags: 0x2d600000000000(node=0|zone=2|kasantag=0xd6)
[    3.939047] raw: 002d600000000000 0000000000000000 dead000000000122 
0000000000000000
[    3.939053] raw: 0000000000000000 0000000000000000 00000001ffffffff 
0000000000000000
[    3.939057] raw: 00000000000fffff 0000000000000000
[    3.939060] page dumped because: kasan: bad access detected
[    3.939064]
[    3.939065] Memory state around the buggy address:
[    3.939069]  ffff80008024c900: 96 96 96 96 96 96 96 96 96 96 96 96 96 
96 96 96
[    3.939073]  ffff80008024ca00: 96 96 96 96 96 96 96 96 96 96 96 96 96 
96 96 96
[    3.939076] >ffff80008024cb00: 08 08 08 08 08 08 fe fe fe fe fe fe fe 
fe fe fe
[    3.939079]                    ^
[    3.939082]  ffff80008024cc00: fe fe fe fe fe fe fe fe fe fe fe fe fe 
fe fe fe
[    3.939086]  ffff80008024cd00: fe fe fe fe fe fe fe fe fe fe fe fe fe 
fe fe fe
[    3.939089] 
==================================================================
[    3.939107] Disabling lock debugging due to kernel taint
[    3.939134] Unable to handle kernel NULL pointer dereference at 
virtual address 0000000000000020


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).

Thanks,
Qu


> 
> Also ensure your mount options resolve similar to
> "rw,relatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvolid=5,subvol=/".
> 
> Failing that, let me know of any significant filesystem differences from:
> # btrfs inspect-internal dump-super /dev/nvme0n1p5
> superblock: bytenr=65536, device=/dev/nvme0n1p5
> ---------------------------------------------------------
> csum_type        1 (xxhash64)
> csum_size        8
> csum            0x97ec1a3695ae35d0 [match]
> bytenr            65536
> flags            0x1
>              ( WRITTEN )
> magic            _BHRfS_M [match]
> fsid            f99f2753-0283-4f93-8f5d-7a9f59f148cc
> metadata_uuid        00000000-0000-0000-0000-000000000000
> label
> generation        34305
> root            586579968
> sys_array_size        129
> chunk_root_generation    33351
> root_level        0
> chunk_root        19357892608
> chunk_root_level    0
> log_root        0
> log_root_transid (deprecated)    0
> log_root_level        0
> total_bytes        83886080000
> bytes_used        14462930944
> sectorsize        4096
> nodesize        16384
> leafsize (deprecated)    16384
> stripesize        4096
> root_dir        6
> num_devices        1
> compat_flags        0x0
> compat_ro_flags        0x3
>              ( FREE_SPACE_TREE |
>                FREE_SPACE_TREE_VALID )
> incompat_flags        0x361
>              ( MIXED_BACKREF |
>                BIG_METADATA |
>                EXTENDED_IREF |
>                SKINNY_METADATA |
>                NO_HOLES )
> cache_generation    0
> uuid_tree_generation    34305
> dev_item.uuid        86166b5f-2258-4ab9-aac6-0d0e37ffbdb6
> dev_item.fsid        f99f2753-0283-4f93-8f5d-7a9f59f148cc [match]
> dev_item.type        0
> dev_item.total_bytes    83886080000
> dev_item.bytes_used    22624075776
> dev_item.io_align    4096
> dev_item.io_width    4096
> dev_item.sector_size    4096
> dev_item.devid        1
> dev_item.dev_group    0
> dev_item.seek_speed    0
> dev_item.bandwidth    0
> dev_item.generation    0
> 
> Thanks,
>    Dan
> --
> Daniel J Blueman

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 14:35, Qu Wenruo 写道:
> 
> 
> 在 2025/12/31 13:59, Daniel J Blueman 写道:
>> On Tue, 30 Dec 2025 at 17:28, Qu Wenruo <wqu@suse.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 + soft tag + inline:	KASAN error at boot
arm64 + soft tag + outline:	KASAN error at boot
arm64 + hard tag:		PASS
arm64 + generic + inline:	PASS
arm64 + generic + outline:	PASS

So it looks like it's the software tag based KASAN itself causing false 
alerts.

Thanks,
Qu

> 
> Thanks,
> Qu
> 
> 
>>
>> Also ensure your mount options resolve similar to
>> "rw,relatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvolid=5,subvol=/".
>>
>> Failing that, let me know of any significant filesystem differences from:
>> # btrfs inspect-internal dump-super /dev/nvme0n1p5
>> superblock: bytenr=65536, device=/dev/nvme0n1p5
>> ---------------------------------------------------------
>> csum_type        1 (xxhash64)
>> csum_size        8
>> csum            0x97ec1a3695ae35d0 [match]
>> bytenr            65536
>> flags            0x1
>>              ( WRITTEN )
>> magic            _BHRfS_M [match]
>> fsid            f99f2753-0283-4f93-8f5d-7a9f59f148cc
>> metadata_uuid        00000000-0000-0000-0000-000000000000
>> label
>> generation        34305
>> root            586579968
>> sys_array_size        129
>> chunk_root_generation    33351
>> root_level        0
>> chunk_root        19357892608
>> chunk_root_level    0
>> log_root        0
>> log_root_transid (deprecated)    0
>> log_root_level        0
>> total_bytes        83886080000
>> bytes_used        14462930944
>> sectorsize        4096
>> nodesize        16384
>> leafsize (deprecated)    16384
>> stripesize        4096
>> root_dir        6
>> num_devices        1
>> compat_flags        0x0
>> compat_ro_flags        0x3
>>              ( FREE_SPACE_TREE |
>>                FREE_SPACE_TREE_VALID )
>> incompat_flags        0x361
>>              ( MIXED_BACKREF |
>>                BIG_METADATA |
>>                EXTENDED_IREF |
>>                SKINNY_METADATA |
>>                NO_HOLES )
>> cache_generation    0
>> uuid_tree_generation    34305
>> dev_item.uuid        86166b5f-2258-4ab9-aac6-0d0e37ffbdb6
>> dev_item.fsid        f99f2753-0283-4f93-8f5d-7a9f59f148cc [match]
>> dev_item.type        0
>> dev_item.total_bytes    83886080000
>> dev_item.bytes_used    22624075776
>> dev_item.io_align    4096
>> dev_item.io_width    4096
>> dev_item.sector_size    4096
>> dev_item.devid        1
>> dev_item.dev_group    0
>> dev_item.seek_speed    0
>> dev_item.bandwidth    0
>> dev_item.generation    0
>>
>> Thanks,
>>    Dan
>> -- 
>> Daniel J Blueman
> 
> 

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)

[Daniel J Blueman]

On Wed, 31 Dec 2025 at 12:55, Qu Wenruo <wqu@suse.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@suse.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?

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.

Thanks,
  Dan
-- 
Daniel J Blueman

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

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@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
> 
> 

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)

[Daniel J Blueman]

On Thu, 1 Jan 2026 at 09:15, Qu Wenruo <wqu@suse.com> wrote:
> 在 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.

This suggests the issue only reproduces with particular
struct/page/cacheline alignment or related; good information!

Dan
-- 
Daniel J Blueman