Message-ID: <01d84dae-1354-4cd5-97ce-4b64a396316a@suse.com>
Date: Tue, 30 Dec 2025 19:26:21 +1030
From: Qu Wenruo <wqu@...e.com>
To: Daniel J Blueman <daniel@...ra.org>, David Sterba <dsterba@...e.com>,
 Chris Mason <clm@...com>, Linux BTRFS <linux-btrfs@...r.kernel.org>
Cc: linux-crypto@...r.kernel.org, Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [6.19-rc3] xxhash invalid access during BTRFS mount



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

Powered by blists - more mailing lists