linux-kernel - 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: <642a3e9a-f3f1-4673-8e06-d997b342e96b@suse.com>
Date: Tue, 30 Dec 2025 19:58:50 +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 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
>>
> 
>