Message-ID: <CACT4Y+Yg0+u6Xq2WTYKmuJj0eGnXw=iYo7yqTZhZWfWpvZJDCQ@mail.gmail.com>
Date: Fri, 6 Feb 2026 07:49:49 +0100
From: Dmitry Vyukov <dvyukov@...gle.com>
To: syzbot <syzbot+51b4c65bb770155d058f@...kaller.appspotmail.com>
Cc: hirofumi@...l.parknet.co.jp, linkinjeon@...nel.org, 
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, 
	sj1557.seo@...sung.com, syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [exfat?] KCSAN: data-race in fat12_ent_put / fat_mirror_bhs

On Fri, 6 Feb 2026 at 07:43, syzbot
<syzbot+51b4c65bb770155d058f@...kaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:    de0674d9bc69 Merge tag 'for-6.19-rc8-tag' of git://git.ker..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=15f240aa580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=8e27f4588a0f2183
> dashboard link: https://syzkaller.appspot.com/bug?extid=51b4c65bb770155d058f
> compiler:       Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/bfedab2f6279/disk-de0674d9.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/f012a4cb8d82/vmlinux-de0674d9.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/acb727c49110/bzImage-de0674d9.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+51b4c65bb770155d058f@...kaller.appspotmail.com
>
> ==================================================================
> BUG: KCSAN: data-race in fat12_ent_put / fat_mirror_bhs
>
> read-write to 0xffff888129151032 of 1 bytes by task 4937 on cpu 1:
>  fat12_ent_put+0xc4/0x170 fs/fat/fatent.c:165
>  fat_ent_write+0x6c/0xe0 fs/fat/fatent.c:417
>  fat_chain_add+0x16c/0x490 fs/fat/misc.c:136
>  fat_add_cluster fs/fat/inode.c:113 [inline]
>  __fat_get_block fs/fat/inode.c:155 [inline]
>  fat_get_block+0x46c/0x5e0 fs/fat/inode.c:190
>  __block_write_begin_int+0x400/0xf90 fs/buffer.c:2145
>  block_write_begin fs/buffer.c:2256 [inline]
>  cont_write_begin+0x5fe/0x970 fs/buffer.c:2594
>  fat_write_begin+0x4f/0xe0 fs/fat/inode.c:230
>  generic_perform_write+0x183/0x490 mm/filemap.c:4314
>  __generic_file_write_iter+0x9e/0x120 mm/filemap.c:4431
>  generic_file_write_iter+0x8d/0x310 mm/filemap.c:4457
>  new_sync_write fs/read_write.c:593 [inline]
>  vfs_write+0x5a6/0x9f0 fs/read_write.c:686
>  ksys_write+0xdc/0x1a0 fs/read_write.c:738
>  __do_sys_write fs/read_write.c:749 [inline]
>  __se_sys_write fs/read_write.c:746 [inline]
>  __x64_sys_write+0x40/0x50 fs/read_write.c:746
>  x64_sys_call+0x2847/0x3000 arch/x86/include/generated/asm/syscalls_64.h:2
>  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
>  do_syscall_64+0xc0/0x2a0 arch/x86/entry/syscall_64.c:94
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> read to 0xffff888129151000 of 512 bytes by task 4940 on cpu 0:
>  fat_mirror_bhs+0x1df/0x320 fs/fat/fatent.c:395
>  fat_alloc_clusters+0xb48/0xc50 fs/fat/fatent.c:543
>  fat_add_cluster fs/fat/inode.c:108 [inline]
>  __fat_get_block fs/fat/inode.c:155 [inline]
>  fat_get_block+0x258/0x5e0 fs/fat/inode.c:190
>  __block_write_begin_int+0x400/0xf90 fs/buffer.c:2145
>  block_write_begin fs/buffer.c:2256 [inline]
>  cont_write_begin+0x5fe/0x970 fs/buffer.c:2594
>  fat_write_begin+0x4f/0xe0 fs/fat/inode.c:230
>  generic_perform_write+0x183/0x490 mm/filemap.c:4314
>  __generic_file_write_iter+0x9e/0x120 mm/filemap.c:4431
>  generic_file_write_iter+0x8d/0x310 mm/filemap.c:4457
>  __kernel_write_iter+0x319/0x590 fs/read_write.c:619
>  dump_emit_page fs/coredump.c:1298 [inline]
>  dump_user_range+0xa7d/0xdb0 fs/coredump.c:1372
>  elf_core_dump+0x21a2/0x2330 fs/binfmt_elf.c:2111
>  coredump_write+0xacf/0xdf0 fs/coredump.c:1049
>  do_coredump fs/coredump.c:1126 [inline]
>  vfs_coredump+0x26bc/0x3120 fs/coredump.c:1200
>  get_signal+0xd7b/0xf60 kernel/signal.c:3019
>  arch_do_signal_or_restart+0x96/0x450 arch/x86/kernel/signal.c:337
>  __exit_to_user_mode_loop kernel/entry/common.c:41 [inline]
>  exit_to_user_mode_loop kernel/entry/common.c:75 [inline]
>  __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]
>  irqentry_exit_to_user_mode_prepare include/linux/irq-entry-common.h:270 [inline]
>  irqentry_exit_to_user_mode include/linux/irq-entry-common.h:339 [inline]
>  irqentry_exit+0xf7/0x510 kernel/entry/common.c:196
>  asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:618
>
> Reported by Kernel Concurrency Sanitizer on:
> CPU: 0 UID: 0 PID: 4940 Comm: syz.3.398 Not tainted syzkaller #0 PREEMPT(voluntary)
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
> ==================================================================


FWIW this is how LLM explained why this race is harmful. It does not
look totally bogus to me.

=======

The data race occurs between `fat12_ent_put()` and `fat_mirror_bhs()`
in the FAT filesystem implementation.

### Analysis:
1.  **Task 1 (`fat12_ent_put`)**: This function is responsible for
updating a 12-bit FAT entry. Because FAT12 entries are 1.5 bytes long
and can span byte boundaries, updating an entry involves a
read-modify-write on two bytes. This is protected by the
`fat12_entry_lock` spinlock to ensure atomicity against other FAT12
entry updates. In the reported stack trace, it is called from
`fat_alloc_clusters()`, which also holds the `lock_fat` mutex.
2.  **Task 2 (`fat_mirror_bhs`)**: This function copies the "main" FAT
blocks (held in `buffer_head`s) to the backup FAT copies (mirrors) on
the disk. It uses `memcpy()` to copy the entire block data. In the
reported stack trace, it is called from `fat_alloc_clusters()`.
3.  **The Race**: In `fat_alloc_clusters()`, the `lock_fat` mutex is
released *before* calling `fat_mirror_bhs()`. This allows another task
(like Task 1) to acquire the `lock_fat` mutex and begin modifying the
same FAT block that Task 2 is currently mirroring. Since
`fat_mirror_bhs()` does not take the `fat12_entry_lock` spinlock, and
`memcpy()` is not atomic, Task 2 can read a FAT entry in a partially
updated (torn) state.
4.  **Impact**: If a torn FAT entry is copied to the mirror FAT and
subsequently written to disk, the filesystem metadata becomes
corrupted. In FAT12, a torn read can result in a cluster pointer that
is neither the old nor the new value, potentially pointing to a random
cluster. This leads to cross-linked files, lost data, or filesystem
inconsistency. While the main FAT might eventually be updated
correctly, there is a window where the mirror is corrupted on disk,
and if a crash occurs, the filesystem is left in an inconsistent
state. A similar race condition exists for `fat_sync_bhs()`, which
flushes the main FAT block to disk.

### Conclusion:
This data race is **harmful**. It involves concurrent access to shared
filesystem metadata without sufficient synchronization, leading to the
possibility of writing inconsistent/corrupted metadata to the disk.
Filesystem metadata integrity is critical, and torn writes are a
well-known source of serious filesystem corruption. The inconsistency
in locking between `fat_free_clusters()` (which holds the lock during
mirroring) and `fat_alloc_clusters()` (which does not) further
indicates that this is an unsafe oversight.

Powered by blists - more mailing lists